Fwd: efficient resync?

> I'd like to learn how to tell when it's really necessary to resync after
> loosing a connection, and whether it's worth it to implement.
>
> While our lab wired networks are solid, wireless can be intermittent and
> ISP's sometimes drop folks overnight. Assuming I arrange to re-establish
> connection automatically (e.g., connect and login), it might not always
> be necessary to sync. And I hate waiting.
>
> One example is where there is no one else from whom to supply a sync:
> you win! Just keep using the island in the state it was in (possibly
> after registering yourself as beServer, setting router time to your
> island time, etc.).
>
> But what about other use cases? One attractive target is "The dropped
> wireless phone call."  You and I are talking by cell phone, and for
> whatever silly reason, the call is disconnected. We both want to
> continue the conversation where it left off.  Even if I the first guy
> back doesn't have to resync, making the second guy back resync will
> still force the first guy to wait the same amount of real time before
> continuing the conversation. Yuck.
>
> I don't know whether it's worth trying to be clever here.  I could
> imagine schemes such as:
>  - using consecutively numbered message to determine if we've missed a
> message before resync'ing, or
>  - examine all the participants' unexecuted time periods (participant's
> island time through the timestamp of the last message they do have),
> assemble into continuous chains, pick the chain that has the most
> member's timestamps within the chain, and then distribute that chain to
> those members for execution. The others will have to resync.
>
> But it might be the case that while something like these might work, the
> performance characteristics are such that they hardly ever really help
> you win.
> Ideas? Discussion?
>
> --
> Howard Stearns
> University of Wisconsin - Madison
> Division of Information Technology
> mailto:[hidden email]
> jabber:[hidden email]
> voice:+1-608-262-3724
>
>
>