EFnet IRC Network Forum

Hello again,

There's been some chat lately about adding features to IRCD code to allow for multiple server links, creating a mesh type network map. This could add greater stability to the network, if done correctly, and could help eliminate the perceived dependence on 'centralized superhubs'. More importantly, it could decrease lag, and save bandwidth, by sending PRIVMSG's via 'iOSPF' directly to the target server.

I've also heard about another new approach to IRC networks in general, where an entire IRC network shares one IP prefix. All the ISP's which host client servers announce via BPG4, with no export, this single prefix. All the users are funneled into the networks main hostname, which is pointed at an IP in this prefix, and depending on where the users get their connectivity from, they'll be automatically routed to the closest IRC server. The drawback is it's clearly not going to be globally routable, and unless you're connected to a direct peer of a hosting server, you're not going to have a route to the IRC network. This has obvious advantages and drawbacks.

Both certainly sound neat, in any case. Comments?

-seiki

seiki wrote:Hello again,

There's been some chat lately about adding features to IRCD code to allow for multiple server links, creating a mesh type network map. This could add greater stability to the network, if done correctly, and could help eliminate the perceived dependence on 'centralized superhubs'. More importantly, it could decrease lag, and save bandwidth, by sending PRIVMSG's via 'iOSPF' directly to the target server.i

Already been discussed with hybrid coders. Problems are desyncs. If you send first an +o Luser then an -o Luser. Lag and the current routing can throw that around so that some server finally sees the -o first and the +o last which will cause heavily desyncs.

Same things goes for "hot spare links" which would be slave-links already setup that kikc in in case of failure of the main link. We can lose messages one the way during the link change.

Sorry, a better idea must be presented.

seiki wrote: I've also heard about another new approach to IRC networks in general, where an entire IRC network shares one IP prefix. All the ISP's which host client servers announce via BPG4, with no export, this single prefix. All the users are funneled into the networks main hostname, which is pointed at an IP in this prefix, and depending on where the users get their connectivity from, they'll be automatically routed to the closest IRC server. The drawback is it's clearly not going to be globally routable, and unless you're connected to a direct peer of a hosting server, you're not going to have a route to the IRC network. This has obvious advantages and drawbacks.

Both certainly sound neat, in any case. Comments?

-seiki

Not all server have BGP. We don't, we dont need to. It also gives one point of failure. Easy to attack that IP, which happened with dal.net's dns-servers.

seiki wrote: There's been some chat lately about adding features to IRCD code to allow for multiple server links, creating a mesh type network map.

does the current hybrid not support this already? (i take it by your post it seems no and this might be a stupid question.) what currently would stop from someone defining every server as a hub and connecting to every server other server right now? what would happen if they did?

for one, if you link to every other server, you'd be wasting a lot of bandwidth. it would also create tremendous server load trying to sort through all the messages and figure out what came in at what time due to lag, etc

if the network were to become a mesh network, a server would most likely not connect to more than 2-3 servers, and it might even be only hubs that meshed, with clients still connecting to only 1 hub.

well i see a sort of hybrid mesh would be affective. i think it is a good idea to use some extra bandwidth as well as a bit more server load to increase the network stability. does anyone agree with me?

so is seiki saying that they should change hybrid to allow better support for mesh networks? in a way that hybrid would choose the best path? this wouldn't this need to modify the protocol to include some sort of routing?

-wassup- wrote: so is seiki saying that they should change hybrid to allow better support for mesh networks? in a way that hybrid would choose the best path? this wouldn't this need to modify the protocol to include some sort of routing?

I'm not saying anything like that. I'm simply curious what people think of the idea of mesh networks. The idea was brought up by another IRCadmin on the mailing lists a few months ago. I personally don't care either way, just wanted to see some further discussion on the subject..

regards,
-seiki