Quote Originally Posted by Shaggy Hiker
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.
Yes, this is what i mean. I was thinking about designing the code that's connectionless, but still on the TCP protocol. This however is not what TCP was designed for. I was going to make a connection to an IP address on a specific port, send the message and then disconnect. But for some reason, this just doesn't feel right. This is why i was going to make it a normal TCP connection, where it connects once, and uses those connections to send the data by. This could also be useful to find out if a client is still online without pinging them in some sort of fashion. If i use the connectionless way, then extra code will be needed on the server to verify that it's a client on their "contact list", It will also be harder to keep 2 clients synchronized, especially if one gets improperly disconnected, also error checking would have to be done to make sure the message got through properly, but it is certainly possible to do this.

Which way would be the better way to go?