If i may... there is another problem i see coming... What about a network where there is many 1-2 sec lag between servers (an example). If, let say, 3 or 4 servers decide to 'jump' at the same time... I wont list all problem that could occur, but there is a need for a pre-jump (to the network and some sort of aknolegment after that) command telling other servers to wait a little before their jump and maybe reconsider after the fist one (via the secondary link of course, and propaging to all servers and secondary link and coming back the same way to say 'oki', but not being stopped if there is no answer at all... (blah)).
There is also the problem that secondary server would be fine for leaf servers, but what about hubs? It's for the hub that it would be the more usefull, but it is also where problems begins: We have to be carefull to avoid some sort of long term netbreak if 1 hub decide to jump to an other hub but creating 2 seperate groups that way... There must be a checking mecanism ;p I don't know it this if this is 'clear' but if you play with a sheet of paper, some dots and line, wou'll see what i mean :o) - Alocin > -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de Kev > Envoyé : Le jeudi 11 avril 2002 12:57 > À : [EMAIL PROTECTED] > Objet : [Coder-Com] RFD: Secondary links > > > 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]> >
