I have an app which acts like a TCP server and accepts multiple connections. Each connection is made by a distinct device, with a unique ID (the ID is reported by the device in two different messages according to its protocol, but that's less important).

Right now, whenever a connection is established, my app creates a new list of parsers for a bunch of messages the device can send, but at that point it doesn't know yet which device has been connected. The problem is that several messages can be parsed before device's identity is established. Since devices can disconnect and reconnect during app's lifetime, there are long lived objects (device statistics and various other data) that should not be discarded whenever a device disconnects, and therefore need to be reattached as the consumers of the parser pipeline once the device ID is established. Alternatively, if a device was never connected before, its fresh instances will become long lived.

Does anyone have an overall idea of how this application should be rearranged? For example, one idea was to wrap the long lived objects into proxies, and then have the possibility to change the underlying implementation with a different instance, once a new device is connected. To make it clearer, these objects are not public singletons (multitons), but there is obviously a dictionary (by ID) somewhere in the business layer to keep track of per-device data.

This all feels unnecessarily complex, but the code (like it always does) obviously evolved over time and now I feel I can't see the forest through the trees.

1 Answer 1


Well, I think you need to clearly and explicitly distinguish two things: a client and a connection.

A connection is something potentially short living. It gets opened (and thereby instantiated), it gets closed (and thereby disposed). It may or may not be associated with a client. It may use this protocol or that protocol, this or that transport layer, etc.

A client (what you call device) is rather long living. You may even wish it to be persistent. Who knows. In any case it holds those "statistics and various other data".

By this reasoning, the parsers and such belong to the connection, rather than the client. In the end all these details about how messages reach your end point of the connection actually should be encapsulated into an object representing the protocol belonging to that connection.

Once your endpoint of a connection receives identification data, it should ask a client manager to provide an according client object to communicate with. The specifics of how the manager works are irrelevant to the overall design. You give it an ID, you get a client. The client manager decides, whether a new object needs to be created, or whether one exists or whether one needs to be build from your persistence layer or whatever.
Once the connection has its client, it can register to it and send all sorts of information to it, or the client in return can watch events on the connection, etc. Once a connection is closed, it must unregister from its client (assuming it has one) and free its protocol.

  • +1 Thanks. It's basically how it works now, with the exception that I didn't want to throw all the persistent functionality into a single know-all client object (God object?). So I ended up with several "client managers", each returning a relevant instance on demand. This is what feels a little awkward: this data is all related to this single object, but I dislike having to add another property to the "client object" for each new functionality that arises. If there is a single object per client, then it's basically a singleton, and I have less issues to implement it, but more to test it.
    – vgru
    Jul 19, 2011 at 11:17
  • @Groo: I don't understand. If there is a single object per client, why would it be a singleton? Do you have only one client for your whole application? As for the rest, you could group the data into separate objects, that are accessible through the according client instance.
    – back2dos
    Jul 19, 2011 at 11:27
  • No, I didn't actually mean it's a Singleton, but rather a Multiton (as the thread title says), a single instance per key object.
    – vgru
    Jul 19, 2011 at 11:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.