This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Users log into a server which stores their information (IP address and UDP port), the connection is then closed.
Whenever someone logs in, he's added to the table of "Online_Users". When a person wants to log out, he'll connect to the server to request logging out.
But what if a client isn't really available anymore and failed to notify the server (Because his connection failed or OS crashed? He'll remain in the table "forever", so I need a method to periodically check who's information is REALLY up-to-date.
Here's the problem, there's no permanent connection between the client and the server!
There are two approaches I can think of:
The server could poll all the "Online_Users" periodically, deleting the clients who don't reply.
Each client can alert the server periodically to avoid being deleted from the table.
So, first question, what's the preferred method to do this? TCP or UDP? And who should take the first step, the server or the client? Please note that I'm keeping the UDP port exclusively for communication between clients, so I'd rather not use it to be contacted from the server.
I don't really need an answer (though I'd love one ), I just need to know the pros and cons of each approach, and what's usually the protocol in these types of applications.
0) Do nothing. A client may appear to be logged on forever. How bad is that?
1) Client sends a keep-alive every n seconds. Any client that hasn't sent a keep-alive in n seconds is presumed dead.
2) The server polls all the clients. Any client that doesn't answer (maybe twice) is presumed dead.
3) The user has to do something to stay alive. If they do nothing after n seconds, the session is dead but we don't know if the client program is still alive. If the user does something after that, they'll have to log in again.
1 & 2 both work and may be necessary if you want fine grained information about how long people use the application. They can introduce lots of tiny network messages and some server overhead, maybe a problem, maybe not. Most web apps I use work like #3.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi