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 <> wrote:

> On Thu, Aug 19, 2010 at 5:33 PM, Benjamin Reed <>
> 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?

Reply via email to