Hello all- I was doing some testing this weekend and hit a new scenario (for me). I'm guessing this is quite common so I was wondering what the standard solutions were. I've got a server with remote clients, communicating via UDP. The client and server are robust in the face of packet loss and network problems, and that seems to work fine. The problem comes up when I kill the client and start a new one on the same host and port. It isn't obvious to the server that the client restarted! It just looks like another network glitch. So the server keeps sending UDP packets to the new client, thinking it's the old client. There's no problem with security (new client doesn't have old client's encryption keys) but it really messes up the bookkeeping on the server. I believe the solution is to have each client process generate a unique ID, and use that to identify itself. The server then uses that ID to keep track of clients. A little bit of thought also tells me that there is no way for the server to reliably tell if a client has been rudely terminated, or if there is just a long network outage. So I guess the server has to time out and disconnect any client if it hasn't heard from it in a while. Look right? -Thomas

The first packet that the client should send to a server should be the equivalent of "hello, there, I'm ready to start talking", and the first packet that the server should send to the client is "okay, let's start talking". Until the client receives that packet from the server it ignores all the other messages it may receive, so there's no ambiguity on the client end, and the server should be prepared to terminate the old connection upon receiving a new "hello" packet, so there's no ambiguity there either. You can use IDs too if you like -- or, taking a cue from TCP, sequence numbers -- but it's not necessary for robust communication in this circumstance.

BTW: Also consider the situation where the server goes down and comes back up without the client noticing. To deal with that, the server should send a disconnection packet in response to packets from unknown clients.

how about having the client send a "I'm Here!" kind of message whenever it starts up.

that way if the server gets that message, it knows that the client has re-connected?

Also if you have a login process, the login process can be the "I'm here!" mesage type thing, which then the server knows to reset whatever states need reseting for the client etc.

Edit: NInja'd by mod (:

Quote:Original post by tomva
A little bit of thought also tells me that there is no way for the server to reliably tell if a client has been rudely terminated, or if there is just a long network outage. So I guess the server has to time out and disconnect any client if it hasn't heard from it in a while.

Also, yes, this is a good idea.