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
Locked
