View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001836 | unreal | ircd | public | 2004-05-25 10:09 | 2015-05-27 18:14 |
| Reporter | doh | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Platform | ALL | OS | ALL | OS Version | ALL |
| Product Version | 3.2 | ||||
| Fixed in Version | 3.2.9 | ||||
| Summary | 0001836: link::backup-link | ||||
| Description | What usually happends when the mainhub splits is that you would like to link to the backuphub ASAP... however there's not really a good way to do that currently AFAIK... unless you set your backup link to autoconnect and connfreq to like 15 seconds ;). Rather it would be easier (and better/faster) to have a link::backup-link thingy where it 'jumps' to as soon as the link is split.. so then if the mainhub splits it IMMEDIATELY connects to the backup link... That way the 'split time' would be reduced a lot. Also... perhaps look at if we could change the behavior of trying to link (autoconnect) even though we already know the server is already connected to the net (see my [Syzop] bugnote later on in this discussion). | ||||
| Additional Information | original description (this is no longer where the bugreport is about): 'This has been talked about around the ircd community for quite a while... the possibility to have servers link up against multiple hubs would give a good boost of reliability on a irc network.. Say you have one primary hub link for leafs.. and two hubs linked up.. if the primary hub fails, the links will use the secondary hub for trafic.. When the primary comes back online, trafic will be routed through that again.. If all this is not possible, how about a way of selecting a preference for multiple hub lines? So that servers will always try to connect to the hub you give priority, if it fails, it will obviously link to the backup.. and keep trying to link to the primary.. when the link to the primary comes back up, it will break the connection to the backup and link back to the primary hub...' | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
| has duplicate | 0002304 | closed | Feature Request - Connect to Alternate Hub |
|
|
Failover-without-split is indeed not possible, but.. your 2nd point/request is similar to something we have been thinking of implementing... I can imagine, however, situations where this is creating chaos... like if the mainhub is not 'stable' or very laggy and disconnects, backup link kicks in (which works fine), mainhub reconnects and backup link gets terminated, however mainhub is still unstable/laggy so gets disconnected after 5-10 mins again... backup link kicks in... etc etc [loop]. That way you end up with MORE splits/annoyance than without the feature. So perhaps there should also be some time parameter or something ;). |
|
|
Yes, a time parameter, that could be set to wait for like 30 mins.. In the mean time the server should keep trying to connect, to check if the hub is online. If no response is detected in one of the connection tries, the timer should then be reset.. That way you will only connect back to the main hub if it has been stable (really just able to be connected to) for whatever the parameter has been set to. Really i dont care for how long it waits before reconnecting back to the main hub.. as long as it does it.. so you dont waste bandwidth over longer time having servers connected to two hubs which leads to incresed routing trafic [edit] Maybe the switch back to the main hub could be done without splitting ? As it doesnt require the leaf to be connected to two hub.. "just" a server link change [/edit] edited on: 2004-05-25 12:48 |
|
|
The first part is too complex for me to even consider. The second part, however, is already implemented using deny link blocks. Except it won't auto reconnect to the primary server. That's a bad idea. Say the primary server is having problems and is splitting, coming back for 2 mins, and splitting again. So leaf1 splits, and reconnects to hub2. hub1 comes back, leaf1 disconnects from hub2 and links to hub1. Hub1 splits, leaf1 reconnects to hub2. Hub1 comes back, leaf1 reconnects to Hub1. Etc. It's better to have it stay on the backup, and have an oper /squit and /connect it elsewhere when the primary is back and is stable. |
|
|
Read the other bugnotes codemastr.. are they not ideas with potential? |
|
|
'Maybe the switch back to the main hub could be done without splitting ?' Again... that's *NOT* doable... it might look easy to you but it's not.. several people have been thinking about it for years and never came with a good solution that doesn't create desynchs/etc etc. |
|
|
Could a time parameter be implemented? Yeah. But still, I see this as creating a needless netsplit. In my mind, the opers should do it. Meaning, say the 30 mins elapses at 8PM (usually a peak time), I don't want a split then! I'd much rather wait until 2AM and do it then. That way, a minimum number of users are affected. And no, it couldn't be done without splitting. Everything needs to be resent. The network layout has changed, and it needs to be reflected in the commands that are sent. |
|
|
Exactly. It's also not something I would ever use on my net ;). But if lots of people want it.... blah. Anyway, I think I'm a bit confused with another issue... What usually happends when the mainhub splits is that you would like to link to the backuphub ASAP... however there's not really a good way to do that currently AFAIK... unless you set your backup link to autoconnect and connfreq to like 15 seconds ;). Rather it would be easier (and better/faster) to have a link::backup-link thingy where it 'jumps' to as soon as the link is split.. so then if the mainhub splits it IMMEDIATELY connects to the backup link... That way the 'split time' would be reduced a lot. |
|
|
Ok, anyways then, could you (codemastr) care to explain how to involve deny link blocks with two hubs? Isnt it just making to connect blocks for each leaf, or am i missing something.. where does the deny link block come in? |
|
|
Well yeah, you could just make to link blocks, but the thing is, it will still try to connect to hub2 even though it is already connected to hub1. So you do: deny link { mask hub2.yournet.com; type auto; rule connected(hub1.yournet.com); }; So that says, "only connect to hub2.yournet.com if you are not connected to hub1.yournet.com" |
|
|
'it will still try to connect to hub2 even though it is already connected to hub1' any idea why do we do that? ;P I don't see any advantages... only disadvantages. |
|
|
Well because if your a hub. If you're a hub, you can be connected to 1 server and still try and connect to another. |
|
|
Well I mean if: servA-servB-servC and I'm servA... will it then still try to connect to servC (if it has autoconnect) even though it knows it's already linked to the net (indirectly)? |
|
|
True. |
|
|
This bugnote as kinda changed direction.. i guess you could rename it to what syzop suggests.. it would still be a nice addition, and save you some trouble when setting up two hubs |
|
|
What about a kind of "mesh" linking rather than spanning tree? It's been done, it works. I'm not going to say anything, cause codemastr would kick my behind but nyeh. |
|
|
First off, no one has yet to create a perfect solution for a mesh network. I know exactly which IRCd you are referring to, and I can assure you, that implementation is far from perfect. I'm not denying it is possible, it is, I simply don't make nearly enough money from Unreal to dedicate a year of my life to doing nothing but coding a mesh network for Unreal. Instead of posting "use a mesh" read the post. He already suggested that, and we said no. Graph theory is not a simple field of computer science, to make a network graph correctly takes an intimate knowledge of graphs, and computer networks. I would have to read volumes and volumes of books to gain enough knowledge to do it correctly, and, unless people don't mind paying thousands of dollars for Unreal so that I can afford to drop out of school, it's not going to happen. By the way, something that "works" doesn't mean it "works well." A car from 1908 worked. It got people where they wanted to go. However, it did not work well. It was incredibly inefficient, slow, and dangerous. Any and all implementions of a mesh network for IRC do not work well. The protocol needs to be rewritten to make it work well, and I'm not ready to make it so all current clients don't work with Unreal. |
|
|
I'm not about to start a war of words or anything, I think that both <that ircd> and Unreal have their places, but as for a mesh not being able to function efficiently, that is plain wrong. It just (really) moves the focus on routing to the fore (i.e. who sends what where and how) Of course it isnt going to be perfect-- It's hardly optomised code or anything, and still taking baby steps (only just approaching the first beta) but it is getting there. My first thought was that a mesh would be undoable-- until I realised that this would mean that one server would not have to propegate something it recieved. etc The only concievable problem I can see with it is that it would create a number of niggly race issues, especially on a network with large geographical differences (time taken to send from a--c could create problems). Back to Unreal. My thoughts are, if no mesh, then to use two links: Both activated, but only _one_ actually sending the data (until it goes down). This just popped into my head now, so I'll do some thinking on it as to how it would work and get back to you. |
|
|
Read what I said, not what you want me to have said. I didn't say a mesh is inefficient. I said *he* implemented it in an inefficient manner. And, again, read the replies. Syzop also said we have no intentions to have 2 lines with one inactive. It's more complex than you think. The network layout is altered. You can't simply pretend it isn't. |
|
|
Mesh is indeed something which is a lot more doable than those other "some backup links" stuff etc (on which I've had LOTS of thoughts, and not only me.. andrew church and various others too)... I wrote an IRC server a few years ago with the mesh concept (any-server-links-to-any)... When doing that I experienced that it can create very funny desynch issues (like if A<->D gets disconnected but all other links are intact). My ircd was pretty limited however so I didn't had to deal with any of the other [real] issues. On your 2nd comment (the keep-the-link-open-but-let-it-idle), it crossed my mind too but... I concluded that just having a link::backup-link fire up immediately (which basically means just an extra connect + like 4 lines of text [server, protoctl, ..]) is fast enough... it would usually be just an extra second, perhaps in some cases a few, but doesn't look worth the effort... link::backup-link is easy and would be just a 30m job to code *edit*oh and obviously I'm not talking about anything "without splits" or something*/edit* edited on: 2004-05-25 23:11 |
|
|
aight, I got bored after syzops first post... but i'm going to add my own thought anyway, I'm not sure this feature would be good to implement. When you start a irc network, you have to factor in a lil down time... Cut and dry I can't think of any way around that. But there are a LOT of steps you can take to make the effects of the missing hub as lil as possible... well I don't know what they are, but they do exist! :) |
|
|
Yes, the network is altered, and you wouldnt pretend it isnt. What I meant was: a----b . / . / c Hope that displayed correctly... kind of _like_ a mesh, BUT: b-c doesnt actually _send_ any data __!@unless@!__ a-c dies. [edit]It didnt display correctly, but you get the gist.[/edit] edited on: 2004-05-25 23:16 |
|
|
In the meantime I already answered that one *grin* :p *edit*what a nice active discussion eh ;)*/edit* edited on: 2004-05-25 23:15 |
|
|
So in summation of my idea, c would still know about a's users, and would still be able to send/recieve without b being involved. [edit]Yes indeed, jumping like it involves hot potatos... I got that message after i added this *groan*[/edit] [edit2]Tell me if I am missing anything[/edit2] edited on: 2004-05-25 23:19 edited on: 2004-05-25 23:33 |
|
|
What I find really funny is that I submitted a similar request (pretty much identical, but with a little less detail) around when I first arrived here. It got veto'd pretty much straight away, I think by either syzop or codemastr lol... So what is going to happen then? |
|
|
You are wrong. We are NOT implementing the backup links in the sense you described or which was first thought about, rather this bugreport is just about link::backup-link which kicks in as soon as link:: splits. Perhaps you should actually READ what was written here? (description + additional info + bugnotes)... Just... an idea. |
|
|
[edit]@syzop[/edit]Can I ask for a reason for the deletion of that bugnote?Thanks. Might help if you reply to one of those two emails I've sent you over the past 4 months too... edited on: 2004-05-27 22:36 |
|
|
Because you were talking crap. You might want to revise the way you jump to all bugs and post bugnotes (hint: READ READ READ!!)... Furthermore, your attitude (/lack of respect) is also not appreciated by everyone. And no, I fail to see why I should reply to your personal emails... You make it sound like answering these emails would be in my (or the project') best interrest, that's not exactly true. I don't have the time to teach you module coding and I don't feel any obligation to explain every idea in my head to you. Thank you for your understanding. When we are at it. Publicly making false allegations (here, on the forum, etc.) is also something that won't make you more beloved. |
|
|
I'll code this next week :) |
|
|
When the link::backup-link was first suggested, I thought it was a great idea. But, now I'm not so sure. Consider this scenario. Leaf1 is acting up, and so I want to delink it, and jupe it. So I type /squit leaf1.* and I start typing /operserv jupe leaf1.mynet.com, but before I finish typing that, leaf1. has already reconnected using the backup-link! Also, should it immediately try the backup-link? Again, I /squit leaf1.* from hub1.* with message "relinking." Basically, there was some desynch, and so I wanted to have it relink. But, it detects the squit, and now auto reconnects to hub2.*. So to get it back where it belongs, I need to /squit it again. That doesn't seem good. What I'm getting at is, there are instances where the delay between autoconnects is useful, such as when you don't want the server to reconnect. And there are instances where retrying the current connection first is useful, such as when you just wanted the server to reconnect. Backup-link would prevent both of those things. |
|
|
Good point. Perhaps we could treat /SQUIT's by opers differently? Looks doable if I see that '/squit <server> waaah' by an oper becomes 'ERROR :Closing Link: serv2.test.net[192.168.5.220] Ein (waaah)' (like set a flag). Then there's still the case of an oper doing /squit but who actually DID want that it jumped to the backup-link... that's... a problem :P So yes, this requires somet thoughts ;). |
|
|
*postpone*.. some more fun stuff first ;). |
|
|
I would probably prefer having it so that oper SQUIT does not trigger backup link. Mainly, if you squit from the hub, it almost certainly means to the leaf that the hub is still alive if it gets the ERROR :Closing link crap. Since backup link is apparently for dead-hub-type situations, it makes sense that since the hub is still alive, link to that. Of course, there will be the time you need it to link elsewhere, so you delay the reconnect (15s might be a good hardcoded value, but I guess something in ./Config or even the backuplink config stuff itself would be better), and if the leaf finds itself connected elsewhere, cancel the reconnect. Oh, and in the case of squitting from the leaf, you can't really tell 100%, except one way: PING the hub to be squitted with a reduced timeout limit (probably = lesser of either reconnect delay or 1/3 of class::pingfreq), and if it doesn't reply, jump to the backup, and if it does, do the nice SQUIT crap and set the delay to reconnect as before. Probably more complex that way, simpler to just fixed reconnect back to that hub after X delay unless oper /connects it elsewhere... *edit* Ugh, of course, this means using timers, and you seem to be rather hateful of timers at present... :P */edit* |
|
|
I merged 0002304 with this, but I forgot to mention that 0002304 talked about something like: "try relinking to server A, and after X times, try server B".. so that's a tad different (but very related) :) |
|
|
Since 3.2.9 (or so) we have safe linking methods that permit you to have connfreqs of like 10 seconds (or whatever you prefer)... basically results in the same thing. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-05-25 10:09 | doh | New Issue | |
| 2004-05-25 11:06 | syzop | Note Added: 0006404 | |
| 2004-05-25 12:46 | doh | Note Added: 0006405 | |
| 2004-05-25 12:48 | doh | Note Edited: 0006405 | |
| 2004-05-25 12:55 |
|
Note Added: 0006406 | |
| 2004-05-25 13:16 | doh | Note Added: 0006407 | |
| 2004-05-25 13:42 | syzop | Note Added: 0006408 | |
| 2004-05-25 13:45 |
|
Note Added: 0006409 | |
| 2004-05-25 13:58 | syzop | Note Added: 0006410 | |
| 2004-05-25 14:03 | doh | Note Added: 0006411 | |
| 2004-05-25 14:04 |
|
Note Added: 0006412 | |
| 2004-05-25 14:08 | syzop | Note Added: 0006413 | |
| 2004-05-25 14:20 |
|
Note Added: 0006414 | |
| 2004-05-25 14:23 | syzop | Note Added: 0006415 | |
| 2004-05-25 14:25 |
|
Note Added: 0006416 | |
| 2004-05-25 14:28 | doh | Note Added: 0006417 | |
| 2004-05-25 15:22 | syzop | Summary | Multiple server links/backup links => Backup links... |
| 2004-05-25 15:22 | syzop | Description Updated | |
| 2004-05-25 15:22 | syzop | Additional Information Updated | |
| 2004-05-25 22:06 | w00t | Note Added: 0006419 | |
| 2004-05-25 22:25 |
|
Note Added: 0006420 | |
| 2004-05-25 22:36 | w00t | Note Added: 0006421 | |
| 2004-05-25 23:06 |
|
Note Added: 0006422 | |
| 2004-05-25 23:07 | syzop | Note Added: 0006423 | |
| 2004-05-25 23:10 | jewles | Note Added: 0006424 | |
| 2004-05-25 23:11 | syzop | Note Edited: 0006423 | |
| 2004-05-25 23:13 | w00t | Note Added: 0006425 | |
| 2004-05-25 23:15 | syzop | Note Added: 0006426 | |
| 2004-05-25 23:15 | syzop | Note Edited: 0006426 | |
| 2004-05-25 23:16 | w00t | Note Edited: 0006425 | |
| 2004-05-25 23:17 | w00t | Note Added: 0006427 | |
| 2004-05-25 23:19 | w00t | Note Edited: 0006427 | |
| 2004-05-25 23:33 | w00t | Note Edited: 0006427 | |
| 2004-05-26 00:31 | syzop | Status | new => acknowledged |
| 2004-05-26 00:31 | syzop | ETA | none => < 1 month |
| 2004-05-26 00:54 | w00t | Note Added: 0006429 | |
| 2004-05-26 11:03 | syzop | Note Added: 0006431 | |
| 2004-05-26 21:57 | syzop | Reproducibility | always => N/A |
| 2004-05-26 21:57 | syzop | Summary | Backup links... => link::backup-link |
| 2004-05-27 22:35 | w00t | Note Added: 0006450 | |
| 2004-05-27 22:36 | w00t | Note Edited: 0006450 | |
| 2004-05-28 00:31 | syzop | Note Added: 0006452 | |
| 2004-05-28 21:44 | syzop | Note Added: 0006453 | |
| 2004-05-28 21:44 | syzop | Assigned To | => syzop |
| 2004-05-28 21:44 | syzop | Status | acknowledged => assigned |
| 2004-05-28 21:44 | syzop | ETA | < 1 month => < 1 week |
| 2004-05-28 21:45 | syzop | View Status | public => private |
| 2004-06-01 15:49 |
|
Note Added: 0006512 | |
| 2004-06-01 16:19 | syzop | Note Added: 0006516 | |
| 2004-06-02 00:22 | syzop | ETA | < 1 week => < 1 month |
| 2004-06-03 17:15 | syzop | Note Added: 0006563 | |
| 2004-06-03 17:15 | syzop | Assigned To | syzop => |
| 2004-06-03 17:15 | syzop | Status | assigned => acknowledged |
| 2004-06-24 21:00 | syzop | ETA | < 1 month => > 1 month |
| 2005-01-25 18:06 | syzop | Relationship added | has duplicate 0002304 |
| 2005-01-25 18:07 | syzop | View Status | private => public |
| 2005-01-26 00:39 | aquanight | Note Added: 0008924 | |
| 2005-01-26 00:40 | aquanight | Note Edited: 0008924 | |
| 2005-01-26 11:54 | syzop | Note Added: 0008928 | |
| 2015-05-27 18:14 | syzop | Note Added: 0018354 | |
| 2015-05-27 18:14 | syzop | Status | acknowledged => resolved |
| 2015-05-27 18:14 | syzop | Fixed in Version | => 3.2.9 |
| 2015-05-27 18:14 | syzop | Resolution | open => fixed |
| 2015-05-27 18:14 | syzop | Assigned To | => syzop |
