The idea is to allow servers to establish a secondary network link.  No
messages (except PINGs) would go across the secondary link unless the
primary link was broken.  This is still a long way from a mesh-linked
network, but might be an interesting enhancement.

We would introduce a new command for unregistered connections to server
ports--SECONDARY.  We would also introduce a new server<->server command
with the token SC.  SC would be prefixed by the introducing server and
would contain the same fields as a SERVER command--lag could lead to some
servers receiving the SECONDARY command before the SERVER command.  We
need to discuss how to represent destruction of a secondary link--is a
SQUIT command enough, or must we introduce another command?  We must also
discuss how the fall-back is to occur--if more than one SECONDARY link
has been established, how do we select which one to fall back to?

My idea for this is that each link--both the primary and secondaries--
have an associated timestamp.  If the primary is lost, the secondary
with the oldest timestamp is promoted to the primary.

I can think of three more problems that must be solved.  The first is
what to do with en-route messages: messages that cross with the SQUIT.
The parser drops messages that are going the wrong direction.  We should
then remove this restriction, but that leads to potentially infinite
message loops under certain types of desynchronization.  The second
problem is what to do with messages waiting in the sendq for the primary
link--they should be resent to the secondary, but might that require
re-parsing them?  The third problem is what to do about certain global
messages required for maintaining network synchronization--some could get
lost during the transition from the primary to the secondary, but we
can't simply have the server deal with multiple copies of the same change
to the database.

So.  Discuss :)
-- 
Kevin L. Mitchell <[EMAIL PROTECTED]>

Reply via email to