At 18:57 11-4-2002, you wrote: >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.
Might be, but it also opens up the possibility of many very subtle bugs >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? Well: do servers other than the 2 having a secondary link need to know the secondary link exists? If no, you don't need to broadcast the creation and destruction of secondary links accross the network. As for fallback, something like this comes to mind: Let leafs have only one secondary link, simple and obvious. For hubs, it gets more complicated: Store a "preferred hub-to-hub routing map" in the hub's .conf, which hubs can use to decide/arbitrate which secondary link to use when the need arises. This has the benefit of requiring no communication between hubs to make the decision. The drawbacks are that the hubs will not be able to make decisions based on useful data such as network lag, ping times etc. It also requires the routing-preferences stored in the .conf of each hub to be consistent. Keeping that map updated in the .conf is also an issue, but a minor one since it would only have to updated when a new hub links or or an existing one delinks. You could also establish something along the lines of a routing protocol between hubs, which allows them to communicate their status (lag, pings, etc); and would allow them to choose the best secondary link to use on the fly without the need for any human input (either from an oper or a .conf file). Obviously this would have to exist outside of IRC-based server-server links (as in, via UDP). >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. But, would you also still allow humans (opers) to overrule and let them set up routing manyally (i.e., /squit and /connect)? For all practical purposes routing is, for the most part, a policy-based decision and not a technical one. >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. Give messages a TTL? > 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? Have servers send an ACK every 2000 (or whatever number) messages, keep all messages sent since the last ACK in a buffer, and resend them via the new link when it comes online? This will keep the number of duplicated down and within predictable limits. >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. How many messages are we talking about? If the number is managebly low, a simple acknowlegement-based system can be used. >So. Discuss :) Could you detail some of the "interesting enhancements" you mentioned? Considering the amount of work this requires (basically it's irc3), they better be good =P /Arjen
