Proxying the multitons

Question

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.

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.