View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003875 | unreal | ircd | public | 2009-11-07 16:12 | 2014-10-25 09:56 |
Reporter | Lupo | Assigned To | syzop | ||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | resolved | Resolution | no change required | ||
Platform | all | OS | all | OS Version | all |
Product Version | 3.2.8 | ||||
Summary | 0003875: Failover links for leaf servers | ||||
Description | It would be neat to have a kind of functionality built in that when a server link fails, the server attempts to connect to another second server. This would allow for automatic repair of the network when a central node of the network goes down. | ||||
Additional Information | Here are two proposals on how the resulting link blocks could look like : Proposal 1 link server.a { username *; hostname 123.231.211.111; bind-ip *; port 6667; hub *; password-connect "pass"; password-receive "pass"; class servers; options { autoconnect; #ssl; zip; }; }; link server.b { username *; hostname 123.231.211.112; bind-ip *; port 6667; hub *; password-connect "pass"; password-receive "pass"; class servers; options { autoconnect; #ssl; zip; failover; }; }; Proposal 2 link uplink; link server.a { priority 1; username *; hostname 123.231.211.111; bind-ip *; port 6667; hub *; password-connect "pass"; password-receive "pass"; class servers; options { autoconnect; #ssl; zip; }; }; link server.b { priority 2; username *; hostname 123.231.211.112; bind-ip *; port 6667; hub *; password-connect "pass"; password-receive "pass"; class servers; options { autoconnect; #ssl; zip; }; }; link server.c { priority 3; username *; hostname 123.231.211.112; bind-ip *; port 6667; hub *; password-connect "pass"; password-receive "pass"; class servers; options { autoconnect; #ssl; zip; }; }; }; | ||||
Tags | No tags attached. | ||||
3rd party modules | |||||
has duplicate | 0003685 | closed | autoconnect |
|
Maybe this should be just considered a documentation bug. Because unrealircd refuses to link to the same server twice, it will take two linkblocks with autoconnect as failover essentially. However, afaik, it will not try the second server immediately after the first link is block (just a guess). And I don't see support for prioritizing link blocks. If better failover support could be provided, it'd probably belong in these areas. The ``mesh links'' setup on stealth's FAQ, http://x-tab.org/unreal.html#meshlink , describes how to do failover. Maybe the existing documentation or official FAQ could be updated so that searching for the keyword ``failover'' will bring the user to a paragraph about how link blocks are automatically exclusive as it takes some intuition to connect the concept of ``failing over'' to ``denying links because accepting the link would create a link loop''. |
|
Does this allow for multiple failover links? it would be handy to have more than one failover link for each link on our network. |
|
lupo/loopy: yes it does. You may place any number of link blocks for any number of hubs you have set up to accept connections. unrealircd will see that these link blocks' associated hub servers are shown in /map when it's connected to at least one of the hubs and thus not try to connect to any but one of the link blocks at a time. When the link falls, unrealircd will try to connect to all of the link blocks until it finds one that works. As others have said on #unreal-support, you probably want to adjust things like connfreq, etc., to make sure that automatic attempts by unrealircd to repair your network are performed in reasonable time, etc. |
|
This CVS Changelog entry is relevant to this (especially the last part regarding 10s):- When our server was trying to link to some server, and at the same time another server was also trying to link with us, this would lead to a server collision: the server would link (twice) ok at first, but then a second later or so both would quit with 'Server Exists' with quite some mess as a result. This isn't unique to Unreal, btw. This happened more often when you had a low connfreq in your link blocks (aka: quick reconnects), or had multiple hubs on autoconnect (with same connfreq), or when you (re)started all servers at the same time. This should now be solved by a new server handshake design, which detects this race condition and solves it by closing one of the two (or more) connections to avoid the issue. This also means that it should now be safe to have multiple hubs with low connfreq's (eg: 10s) without risking that your network falls apart. This new server handshake (protocol updates, etc) was actually quite some work, especially for something that only happened sporadically. I felt it was needed though, because (re)linking stability is extremely important. This new feature/design/fix requires extensive testing. This feature can be disabled by: set { new-linking-protocol 0; }; On another note, I agree we need some additional section or text regarding linking. It doesn't need to be big, but just a few good guidelines. As for http://x-tab.org/unreal.html#meshlink note that the deny link {} stuff is no longer needed nowadays, as Unreal no longer tries to link to a server if it sees it's already on the network. So basically, the suggestion is just to make all leafs link to all hubs with a quick connfreq, or if you don't have hubs, link them with a quick connfreq all to eachother. And as with the fix I mentioned in the beginning of this note, a very low connfreq won't hurt anymore either (starting from Unreal3.2.9). |
|
As stated, with the ability to quickly reconnect (even every 10s) nowadays, this feature is no longer needed. |
Date Modified | Username | Field | Change |
---|---|---|---|
2009-11-07 16:12 | Lupo | New Issue | |
2009-11-07 23:05 | ohnobinki | Note Added: 0015952 | |
2009-11-10 00:33 | Lupo | Note Added: 0015954 | |
2009-11-10 01:28 | ohnobinki | Note Added: 0015955 | |
2010-01-10 16:53 | syzop | Note Added: 0015998 | |
2010-08-04 22:23 | ohnobinki | Relationship added | has duplicate 0003685 |
2014-10-25 09:55 | syzop | Note Added: 0018261 | |
2014-10-25 09:55 | syzop | Status | new => resolved |
2014-10-25 09:55 | syzop | Resolution | open => no change required |
2014-10-25 09:55 | syzop | Assigned To | => syzop |