If multiple clients are connected, then the TCP/IP socket for each of the connected clients remain open as long as the client keeps it open. So, I suspect the decision about where to send the async ClusterResponse messages is being made by the EZSrve software. My guess is that the EZSrve software is not keeping track of the state of inbound commands received from clients and of the insteon messages received from devices that may or may not be responses to the client commands. So, EZSrve simply figures that it should send any Insteon messages it receives to the client that most-recently issued a command, figuring that the Insteon message is likely a response to the client message. Of course, when multiple clients are connected, that logic can often be wrong. For example, if multiple clients issue commands at nearly the same time, and expect to get a response, then the last client to issue its command will get all of the responses, and the other clients will get none.
To correctly route Insteon messages to multiple clients, EZSrve would have to keep track of the commands it has received from the various clients, and route the responses that correspond to the in-process commands. Of course, this could get very complicated, when taking into consideration all of the errors and timeouts that might occur. Then there’s the question of figuring out whether a ClusterResponse message is an async message or a response to a command sent by some client. And, where should you send the Insteon responses if two clients issue the same command to the same device at the same time?
A simpler design that would also allow for multiple clients would simply be to send all insteon messages to all connected clients. Then, it would be up to each client to figure out which messages are responses to its own commands, or async messages that it wants to handle.
It would be interesting to hear from the engineers at smartlabs about all of this.