View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003492 | unreal | ircd | public | 2007-07-31 05:36 | 2009-07-24 01:07 |
| Reporter | P21YALPHA | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | open | ||
| Product Version | 4.0-devel | ||||
| Summary | 0003492: U4 circuits and mesh links | ||||
| Description | FEATURE REQUEST of mesh structuring or/and circuit structuring an unrealircd network. To prevent network splits and maybe to include intelligent link restructuring in runtime. :) It would be a very nice improvement. | ||||
| 3rd party modules | |||||
|
|
Sounds very interesting, don't really know how possible it is, but I would defiantly love to see this. |
|
|
It would have 3 major Problems, which i have the basic ideas to solve 'em. 1. Problem: Message Loops! Solution: Prefix every Message with an unique Transaction ID. Store a transaction log, which keeps track of Messages already sent or not. (Transactions which might be answered by a "OK, Transact ID has arrived") ;) 2. Problem: Routing Messages (mesh structures) Solution: Implement a simple message based Routing protocol. Store Network Map on every server. 3. Problem: Dynamic runtime link reorganization Solution: Adapt the Spanning Tree Protocol (STP, IEEE 802.1 D) for ircd needs. :D Let irc deamons calculate best link ways, etc... Maybe combine it with the suggestion in Problem 2. I know boys, this sounds of pretty hard work. But hey! If you would implement such features, unrealircd networks would be near to 99% aivailability. Stable and very impressive. PS.: I can help at the design, if you need help. :) |
|
|
Mesh links use a lot of bandwidth and are not really practical for the IRC protocol. |
|
|
Which hasnt yet been proven. Remember the internet, how can this big mesh survive? ;) |
|
|
The solution to this is just to have reliable servers hosting your network. Netsplits will happen but if your servers are all in reliable data centers, they will happen less often. A mesh simply would be so difficult to implement for IRC communication, that it is not worth the effort. InspIRCd used to use mesh linking but scrapped it for the current spaningtree protocol because of these exact issues. |
|
|
Did this mesh reorganize its links dynamically while no oper did have to take hands on it? I see no issues on data centers, while servers are located in different countries/continents. One simple message would inform the Servers of a topology change, and the rootircd would intruct rest of the servers how to reshape without any network interference. Linking any Server back again, the network might reshape or the rootircd would inform the homecoming server to link to whatever. It depends on how you implement it, which values how much traffic it produces. :) |
|
|
This is already planned by the Insp coders, I don't know if we will be implementing it before them or not. |
|
|
Say your network has 5 servers. Every message to a channel is sent to 4 different servers. This means 4x the traffic on your network. While a mesh sounds good, the practicality is not really there. Using failover links is just as good. |
|
|
I was going to say, isn't this planned or being implemented by the InspIRCd team? |
|
|
[quote]Say your network has 5 servers. Every message to a channel is sent to 4 different servers. This means 4x the traffic on your network. While a mesh sounds good, the practicality is not really there. Using failover links is just as good.[/quote] This is technically true of spanning tree (only the bandwidth is spread out more, except the in the case of a single hub). But in a mesh, with the rule of thumb for channel messages of not sending where it isn't needed, sometimes bandwidth can be saved. Spanning tree you'd have to send up if even one server along the path has a user in the channel, which could easily involve 3 or 4 other servers that do nothing but pass it on. With mesh, ideally, you would only send to your direct uplink if that uplink has someone in the channel. Although perfect meshes aren't always possible, I believe originally insp accounted for this with route messages which allowed for basically simulating the appearance of a perfect mesh in the absence of an actual perfect mesh. There is one issue with meshing though: the decentralized nature that structure invokes gets shot straight to the deepest underworlds when traditional services are added, because they reintroduce something centralized, and reintroduce the headache of significant service interruption when just the right server goes kersplat, whereas normally one server goes out, the users on it just reconnect on a different one and carry on like nothing happened. The solution is to use ircd-side services with a module, with databases shared via replication or whatever, but to my knowledge, nothing of this nature has been implemented even for unreal3. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-07-31 05:36 | P21YALPHA | New Issue | |
| 2007-07-31 05:38 | TheSkorm | Note Added: 0014632 | |
| 2007-07-31 10:04 | P21YALPHA | Note Added: 0014634 | |
| 2007-07-31 10:11 | owine | Note Added: 0014635 | |
| 2007-07-31 10:13 | P21YALPHA | Note Added: 0014637 | |
| 2007-07-31 10:17 | owine | Note Added: 0014638 | |
| 2007-07-31 10:20 | P21YALPHA | Note Added: 0014639 | |
| 2007-07-31 10:31 | P21YALPHA | Note Edited: 0014639 | |
| 2007-07-31 16:14 | Stealth | Note Added: 0014644 | |
| 2007-07-31 17:29 | owine | Note Added: 0014645 | |
| 2007-07-31 17:44 | TheEggMan | Note Added: 0014646 | |
| 2007-07-31 17:45 | TheEggMan | Status | new => acknowledged |
| 2007-08-28 22:18 | aquanight | Note Added: 0014746 | |
| 2009-07-24 01:07 | Stealth | Status | acknowledged => closed |
