On Oct 16, 2004, at 4:27 PM, Alex Tweedly wrote:
At 21:24 16/10/2004 +0200, Tomas Franz�n wrote:
Dar, Xavier, Bj�rnke,
Thanks for your suggestions.
I will let the server send a ping command to the client, and let the client respond.
When the server hasn't received a ping for a while, it considers the client gone, and vice versa.
If it were me, I'd make the client send the "ping" and the server respond. It's equally effective for keeping track of connections, and keeps the "sense" of initiation and reaction right (for my way of thinking of client/server).
And I'd be traditional, and set it up so the keep-alives should happen every N seconds - and the server only assumes loss of connection if 3 * N seconds have elapsed since the last ping was received. You might even allow clients to have different keep-alive timer values (various reasons why you might want that), and then they should pass their timer value to the server, so it can use the appropriate time-out logic. (And possibly thereby avoid a potential future bug if you need to change the time-out value and operator error leads to it being configured differently between the two ends).
I concur with Alex.
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.
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).
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.
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.
Ah, network protocol design, fun stuff.
Kee Nethery
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
