-1

I am writing a program for monitoring communications between a server and multiple clients on a network. In particular Websocket protocol based communications. I construct monitoring objects for every client that connects to the server and route the information and trigger events for logging purposes.

I am looking for a design pattern that I can use to monitor the Websocket protocol's handshake and state changes ? Are there any design patterns that I can apply ? State pattern or just use a state machine ?

Frank Bryce
  • 938
  • 1
  • 6
  • 15
CodeWeed
  • 109
  • 5
  • I'm not sure what you're looking for. Maybe the [Observer Pattern](https://en.wikipedia.org/wiki/Observer_pattern)? But since you are already using an event system, that would be a step back. How specifically does your current solution fail to meet your requirements? With the information given, I can only guess. – amon Jul 01 '16 at 12:56
  • @amon I need to capture the state changes of Websocket communication for every client, if it is a proper protocol handshake then make an object to reflect the connection details, state, etc. There are concurrent connections the server. I am at the design phase, so I am approaching the problem with some thoughts, rather than creating a big ball of mud. I am not sure how to handle the state capture of each connection with Observer pattern. – CodeWeed Jul 01 '16 at 13:19
  • @gnat I understand the question is a bit of "find the pattern type please". I guess many people write state machine related programs and there must be a pattern to write protocol state machines. I was wondering whether this should be state pattern or just plain old table based state machine. – CodeWeed Jul 01 '16 at 13:38
  • 3
    What does the protocol handshake look like? – Robert Harvey Jul 01 '16 at 13:48
  • @RobertHarvey It is described in the RFC for Websocket Protocol. – CodeWeed Jul 01 '16 at 16:34
  • [RFC 6455?](https://tools.ietf.org/html/rfc6455) – gnat Jul 01 '16 at 16:40
  • @gnat Yes you are right! – CodeWeed Jul 01 '16 at 17:07

1 Answers1

1

I'd suggest breaking up your design into pieces as follows

First, build a communication contract between the clients and the servers. The client should use an abstraction of this contract and not worry that it is actually communicating over a websocket.

Next, build an implementation of the contract(s) to communicate over a websocket. This could use a decorator pattern, and decorate the implementation with two items.

  • Step 1: log the call
  • Step 2: call to the web socket

This way, you can test and design the call to the web socket separately from how the client uses the contract. Further, you can build only one "log the call" decorator for every one of your contract implementations. More use of less code is a good thing :).

While you could build a logging decorator in any language, here is a link to a python logging decorator library to give you an idea of what I mean if you're curious.

More on Step 2

If you have some sort of handshake protocol where one contract will require several websocket calls and receives, then there is another question to consider around flow control.

  • Blocking? Should the contract be blocking until all calls are completed, or
  • Asynchronous? Should the client be able to access the contract in an asynchronous way, or
  • Promise based? Should the contract is promise based? (popular for web-based clients)

If you log the call with the state at each step of your protocol, you can easily track the state of your handshake.

Community
  • 1
Frank Bryce
  • 938
  • 1
  • 6
  • 15
  • I am actually monitoring the network packets, i.e. passively monitoring the tcp packet streams from different connections happening on the network. My initial thought was to use State pattern but then I felt that, creating many objects ( context class, concrete state classes ) for each connection happening on the network, would be an overkill. – CodeWeed Jul 01 '16 at 16:59