View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002213 | unreal | ircd | public | 2004-12-03 02:44 | 2015-05-28 18:43 |
| Reporter | ajh16 | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Platform | n/a | OS | n/a | OS Version | n/a |
| Product Version | 3.2.3 | ||||
| Summary | 0002213: Conditional Linking Logic | ||||
| Description | I work with a multi-server network and we experienced a problem where our hub system and services server were taken offline because of network trouble. This caused a netsplit and loss of services. I had an idea to fix this using conditional linking logic. Basically I want something like an if statement for the unrealircd.conf that would allow you to say if a certain server couldn't be contacted, try contacting another server. It would also be helpful to be able to allow a server to connect if and only if another server wasn't connected. (For example if services.mynetwork.com was connected then servicesbackup.mynetwork.com would not be allowed to connect, but if services.mynetwork.com stopped operating, servicesbackup would immediatly be able to connect and take over.) I would be open to helping with development of this addition, but I would need some assistance in getting familiarized with the code that parses the configuration file and how currently linked servers are stored. (I simply don't have enough time to read through all the source code trying to find it at this point.) | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
While I'm not really into this, at least part of what you asked can be done via the "deny link" block which supports crule expressions. |
|
|
As far as I can tell, deny link would do everything you described. Basically, it supports making complex boolean expressions to determine whether or not a link should succeed. But, based on the overwhelming number of requests for this feature, it sounds as though there should be more documentation available to explain how to use this. |
|
|
I had another question that I couldn't find in the documentation that might be a better idea for a feature, or perhaps for better documentation. Is there or could there easily be a way to have servers be able to adjust for a hub going down. I know how to make a services backup now, but is it possible to make the UnReal servers only link if there wasn't a connection to another hub. (For example, if 3 servers, A, B and C exist, server A will be the hub which B and C link to, however should A fail, C will now automatically connect to B, but will continue to check for A's return and switch back when A returns.) I was able to get it so that B and C would start communicating, but they then ignored A when A came back. |
|
|
[quote]but will continue to check for A's return and switch back when A returns[/quote] Could we make such a feature? Yeah. But our opinion is that it's a bad idea. Consider this, A is on the fritz. It disconnects, and therefore C connects to B. Suddenly, A returns. Therefore, C disconnects from B and goes back to A. However, 5 seconds later, A splits again. Now C must go back to B. If A is being attacked or is having network problems, it could split/come back several times in a relatively short period of time. Therefore, you're causing even more netsplits by having this feature. |
|
|
Yes, it is better to just hang on to a good link than switch back to "preferred" hub, but perhaps something like this: if the link to A drops and comes back quickly (but not before C had already relinked to B), C could relink back to A thinking "eh, maybe it was just a random drop". But if the link to A drops again before a certain threshold (connfreq? HANGONGOODLINK? something else?), C links back to B and stays there until it's manually rerouted by an oper, or the link to B drops (in which case, it goes to trying both until it gets one). If A doesn't come back quickly enough, just sit on B until rerouted manually. On the other hand, this could easily be done by just having C not link to B right away, try to link back to A first, and then if A doesn't respond, go to B and sit there until rerouted... which I think it will do currently :) . As an option to do the actual "switch back", define "A coming back" as C seeing A introduced behind B via the appropriate SERVER message. If C doesn't see an SQUIT for A within a certain threshold (connfreq? HANGONGOODLINK? something else?) then C squits B and links back to A (but possibly before doing this, start the connection to A and only if the connection is established break the link to B). Otherwise, sit on B until rerouted manually. Yeah it's a long shot; like I said, it's probably better to just hang on to whatever it's got, and let the opers deal with it (maybe even services, by firing off appropriate SQUIT and CONNECT messages?). |
|
|
Since 3.2.8 or 3.2.9 it's no longer a problem if you connect to X servers at the same time, UnrealIRCd will deal with it. Previously this resulted in chaos and de-linking servers, but not anymore. Therefore this is no longer needed. Just put autoconnect in all your link blocks to your hubs and use a low connfreq. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-12-03 02:44 | ajh16 | New Issue | |
| 2004-12-03 11:23 | syzop | Note Added: 0008467 | |
| 2004-12-03 15:03 |
|
Note Added: 0008471 | |
| 2004-12-09 17:03 | ajh16 | Note Added: 0008565 | |
| 2004-12-09 17:09 |
|
Note Added: 0008566 | |
| 2004-12-09 20:39 | aquanight | Note Added: 0008570 | |
| 2007-04-27 04:52 |
|
Relationship added | child of 0003286 |
| 2007-04-27 04:52 |
|
Status | new => acknowledged |
| 2015-05-28 18:42 | syzop | Note Added: 0018375 | |
| 2015-05-28 18:42 | syzop | Status | acknowledged => closed |
| 2015-05-28 18:43 | syzop | Assigned To | => syzop |
| 2015-05-28 18:43 | syzop | Resolution | open => no change required |
