6 ms·

We nearly broke EsperNet with about 500 users which were proxies into Minecraft servers. We used a Minecraft mod called EiraIRC. The constant connection and tra

We nearly broke EsperNet with about 500 users which were proxies into Minecraft servers. We used a Minecraft mod called EiraIRC. The constant connection and traffic from these users required a fair amount of interaction and management between us and the staff. And Espernet is not a small network by IRC standards. The problem is that all traffic has to be carried to all nodes brokering connections for a channel. When you have a LOT of traffic this gets onerous. You CAN scale these channels. But it requires some experience and most people never even consider that there might need to be action taken. The Freenode admins know what they're doing, and I respect them enormously for keeping freenode as responsive as it is on what amounts of a 25 year old, bad implementation of a distributed algorithm.

kbuck 11y ago
EsperNet server administrator here. You did not 'nearly break EsperNet' with EiraIRC usage. Our capacity vastly exceeds our load (we could likely run the entire network from a single one of our servers). However, the time our administrative team has to spend differentiating abusive bots from non-abusive ones is finite, which is why we place so many restrictions upon bots.
- KirinDave 11y ago
  I do not doubt you. But that's not what we were told. Another admin from espernet basically had us kill the project because they said the way Eirc was using the system constituted a "significant load" and "would not scale well". We were growing really fast and proxying maybe 3-10 users per bot connection on average. I think your team came to us with the problem right as we were really exploding with users. We basically massively scaled back that deployment of a really cool and interesting feature. Because we didn't want to be an undue burden on our gracious hosts. Now you tell me that this was just some admin giving us an exaggeration? That's a very frustrating detail to learn. Probably not your fault, but thanks for the clarification I guess.
  - kbuck 11y ago
    There are many issues that prevent us from easily serving your use-case, unfortunately. I'm not completely sure about the details around this specific case, but historically we've had to restrict connections from similar software that makes N:N connections (or even N:M connections) to our network due to our connection limit rules quickly becoming unmanageable. We've recently implemented new software that should make this a little bit easier for us (and we've accordingly started being a bit more lax about it), but this is a fairly recent development. Additionally, we hesitate to cater to this use-case as it often ends up turning into "we want your network to relay messages between our bots" instead of "we want to talk to other people". We've found that channels used for such bots are typically not sufficiently staffed and frequently a target of abuse, which ends up taking network staff time to resolve. Lastly, we've had a number of technical issues supporting certain pieces of IRC client software. Older versions of EiraIRC in particular have some nasty bugs; the worst of which is that they tend to get stuck in some state where they hold multiple connections to the network open while continuing to attempt to connect again and again, with no delay. While this doesn't impose load that our servers can't handle, it does generate a lot of administrative log traffic that is bogus and dilutes important log traffic. Many of these use cases can be covered by IRC, but our network isn't configured to handle such use easily as it often looks very similar to the sort of abuse we usually deal with. The common denominator in most cases like this is that it's taking too much of the staff's time and attention to support the channel and its clients. Our time is finite, and for the health of our network, we'd rather say "no" to a few channels than to make all channels suffer from thinner network staff resources.
    - cthalupa 11y ago
      Everything you've said in these past few comments basically boils down to: "Your use case would basically break EsperNet (but it's because of our implementation! We have a lot of issues with our implementation but they're not because IRC can't handle it!)." If the protocol's limitations mean that their use case is not viable due to the strain it places on the administrative side, it's still a limitation.
      - 11y ago

kbuck 11y ago

EsperNet server administrator here. You did not 'nearly break EsperNet' with EiraIRC usage. Our capacity vastly exceeds our load (we could likely run the entire network from a single one of our servers). However, the time our administrative team has to spend differentiating abusive bots from non-abusive ones is finite, which is why we place so many restrictions upon bots.

KirinDave 11y ago
I do not doubt you. But that's not what we were told. Another admin from espernet basically had us kill the project because they said the way Eirc was using the system constituted a "significant load" and "would not scale well". We were growing really fast and proxying maybe 3-10 users per bot connection on average. I think your team came to us with the problem right as we were really exploding with users. We basically massively scaled back that deployment of a really cool and interesting feature. Because we didn't want to be an undue burden on our gracious hosts. Now you tell me that this was just some admin giving us an exaggeration? That's a very frustrating detail to learn. Probably not your fault, but thanks for the clarification I guess.
- kbuck 11y ago
  There are many issues that prevent us from easily serving your use-case, unfortunately. I'm not completely sure about the details around this specific case, but historically we've had to restrict connections from similar software that makes N:N connections (or even N:M connections) to our network due to our connection limit rules quickly becoming unmanageable. We've recently implemented new software that should make this a little bit easier for us (and we've accordingly started being a bit more lax about it), but this is a fairly recent development. Additionally, we hesitate to cater to this use-case as it often ends up turning into "we want your network to relay messages between our bots" instead of "we want to talk to other people". We've found that channels used for such bots are typically not sufficiently staffed and frequently a target of abuse, which ends up taking network staff time to resolve. Lastly, we've had a number of technical issues supporting certain pieces of IRC client software. Older versions of EiraIRC in particular have some nasty bugs; the worst of which is that they tend to get stuck in some state where they hold multiple connections to the network open while continuing to attempt to connect again and again, with no delay. While this doesn't impose load that our servers can't handle, it does generate a lot of administrative log traffic that is bogus and dilutes important log traffic. Many of these use cases can be covered by IRC, but our network isn't configured to handle such use easily as it often looks very similar to the sort of abuse we usually deal with. The common denominator in most cases like this is that it's taking too much of the staff's time and attention to support the channel and its clients. Our time is finite, and for the health of our network, we'd rather say "no" to a few channels than to make all channels suffer from thinner network staff resources.
  - cthalupa 11y ago
    Everything you've said in these past few comments basically boils down to: "Your use case would basically break EsperNet (but it's because of our implementation! We have a lot of issues with our implementation but they're not because IRC can't handle it!)." If the protocol's limitations mean that their use case is not viable due to the strain it places on the administrative side, it's still a limitation.
    - 11y ago