Actually, a dictionary doesn't sound like the right way to go for me. It sounds like you want a class. The class would hold the identifying characteristics of a server. I call it a server, because each program will be a server, listening for incoming calls, but each will also maintain a list of others, and when they call them, they will call as a client. That list can be maintained and built as new clients call in to the server portion of the program. The class will contain all the information necessary to create an endpoint such that it can expose a method that takes a message as an argument, establishes a connection, and sends the data.

This may be a misunderstanding of what you are trying to accomplish. It seems to me that the whole design could be that a server is listening, when an incoming connection request is received, it accepts the connection, gets the remote endpoint from the connection, checks to see if it is on the list of known communicants (and adds it if it is not), then either just takes the message and drops the connection, or takes the message, returns a reply, then drops the connection. That last part might not be ideal, but most of my experience is with UDP. My thinking is that if each server is accepting a connection, receiving a message, then dropping the connection, the tasks are pretty simple, as you are not maintaining the state of a series of connections. Each client establishes a connection, sends a message, then exits. What I don't know is how much time is spent establishing a connection in TCP. If that time is insignificant, then this model would work well, because you don't have to know what the connection status is with any given client.

Alternatively, when you accept a connection in the server side, you get a new socket. Check the list of classes to see if that particular client is on the list, and if it is not, create it, while passing the new socket to the class. If the client is already on the list, then just pass the new socket to the client. All communication over that socket is encompassed by the class. The class maintains the socket as long as the connection is maintained, but even after the socket is destroyed, the endpoint information for that client is maintained in the class such that a new communication can be established as needed.