I concur with Alex.
I agree it would seem more logical to make the client send the keep-alive, and have the server respond, when considering the client/server relationship. Right now, the client is basically built so it can only send requests, and receive replies. In this case, letting the client do the requesting of the keep-alive command, would save me a lot of work, not needing to modify it both to send and receive new commands.
However, I consider the message first sent to be a check if the other end is alive, and in that case, it'd seem logical for the server to send the initial command, and update its user list according to the result (getting a reply or not).
I need the client to receive new commands anyway, so I think I need to modify it even if I let the client send the 'ping'.
Since you own both the client and the server I agree with Alex except I'd make it 3.5 * N so that you don't kill the connection just as the keep alive from the client comes in.
Makes sense.
Put a version number into the client and server keep alive packets (this is the maximum version keep alive packet I know how to send) and have the server respond with a version number (this is the version number I want you to send that is within the range of version numbers you are capable of OR here is the text message to display to the user since I'm not going to support you). Building in a version number for the server and client keep alives lets you add additional information into the keep alives while being backwards compatible with your installed base.
As for potential additional features, of which there are an infinite number that you could add without doing any useful work, I'd have the client send a keep alive with an incrementing integer (that cycles back to 0 when the max value is reached) and have the server return that value so that the client understands whether all keep alives are getting through. If not, the client might want to increase the value of N that it sends to the server and keep it's value of N the same (knowing that there is a failure rate).
Yes, I do something like this now. I call my protocol RSCP, and it's rather human-readable, a lot like HTTP.
It's used for monitoring students in a school. Teachers can keep and eye on what they're doing, and take actions based on that.
I call the incrementing number 'Request-Id'. This id can be any alphanumerical value, and is generated by whoever sends the initial request. It's similar to tags in IMAP.
A sample request might look like this:
RSCP/1.0 AUTH Request-Id: abc123 Content-Length: 21
myUserName myPassword
... and this could be the reply:
RSCP/1.0 OK Request-Id: abc123
... which means that the login was successful.
Also, have the client time it's keep alives based upon the time the last server reply was received, not the time when the client last sent it. Reason being that if a server is under heavy load just servicing keep alives and it takes time to reply because of that load, you could have all the clients sending a keep alive at exactly the same time which could cause problems for the server. If they delay their next keep alive starting from the time they received their last server reply, the server is going to spread them all apart just by the nature of it being a server and sequentially providing each client with a response.
Good point! I'll keep this in mind.
Finally, always keep your keep alive packets to a size small enough to fit into one single ethernet packet. Don't exceed that length for something as simple as a keep alive.
As you can see, my requests are not very small. A keep-alive might look like this, I suppose:
RSCP/1.0 KEEPALIVE Request-Id: 123
Will this fit into a single ethernet packet? I don't know much about this kind of lower level stuff.
Ah, network protocol design, fun stuff.
Indeed. :-)
In my situation, I use two kinds of clients, the 'master' (teacher), and the 'client' (student), and both connect to the main server, which keeps track of who is online. Also, the student is a server, too, responding to commands from the master. Ah, tricky stuff.
Tomas Franz�n Lighthead Software http://www.lightheadsw.com/
I'm listening to Cake - When You Sleep
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
