Ben's approach is really simpler. The client already sends keep-alive messages and we know that some have gone missing or a time shift has happened. Those two possibilities are cleanly distinguished by Ben's suggestion of comparing current time to the bucket expiration. If current time is significantly after the bucket expiration, we know something strange happened and can reschedule the next few buckets.
As Ben mentioned, this has a cleanly bounded maximum error and is very, very simple. He didn't mention that it doesn't require any more information than is already known and doesn't require any machine interaction. On Thu, Aug 19, 2010 at 3:16 PM, Vishal K <vishalm...@gmail.com> wrote: > > On Thu, Aug 19, 2010 at 5:33 PM, Benjamin Reed <br...@yahoo-inc.com> > wrote: > > > if we can't rely on the clock, we cannot say things like "if ... for 5 > > seconds". > > > > > "if ... for 5 seconds" indicates the timeout give by the socket library. > After the timeout we can verify that the timeout received was not a side > effect of time jump by looking at the number of ping attempts. > > > > > also, clients connect to servers, not visa-versa, so we cannot say things > > like "server can attempt to reconnect". > > > > In the scenario described below, wouldn't it be ok for the server to just > send a ping request to see if the client is really dead? >
