View Issue Details

IDProjectCategoryView StatusLast Update
0003875unrealircdpublic2014-10-25 09:56
ReporterLupo Assigned Tosyzop  
PrioritynormalSeverityfeatureReproducibilityN/A
Status resolvedResolutionno change required 
PlatformallOSallOS Versionall
Product Version3.2.8 
Summary0003875: Failover links for leaf servers
DescriptionIt 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 InformationHere 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;
                };
    };
};
TagsNo tags attached.
3rd party modules

Relationships

has duplicate 0003685 closed autoconnect 

Activities

ohnobinki

2009-11-07 23:05

reporter   ~0015952

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''.

Lupo

2009-11-10 00:33

reporter   ~0015954

Does this allow for multiple failover links? it would be handy to have more than one failover link for each link on our network.

ohnobinki

2009-11-10 01:28

reporter   ~0015955

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.

syzop

2010-01-10 16:53

administrator   ~0015998

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).

syzop

2014-10-25 09:55

administrator   ~0018261

As stated, with the ability to quickly reconnect (even every 10s) nowadays, this feature is no longer needed.

Issue History

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