Jump to content
  • Advertisement
Sign in to follow this  
tomva

Client identification

This topic is 3211 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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 (:

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!