4 ms·

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

by 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.
    - e12e 11y ago
      I read that more as: "your use case looks like the way people attack our network (and people actually do attack our network). It is too much work to enable your bots to run what amounts to simulated attacks, when what we want is a network for people to communicate with each other". It certainly is a limitation, but any kind of service needs DDOS mitigation.
      - KirinDave 11y ago
        Why did you write this post?
  - KirinDave 11y ago
    I am intimately aware of the EiraIRC bugs. I helped diagnose the cause of more than a few that we relayed back to the mod author. Personally, I think that you're describing a lot of limitations that we nearly crashed into with the specific implementations of EsperNet at the time. I think if a more modern system were brought to bear on the problem, they wouldn't exist. But that's all speculation; I don't know EsperNet's current or previous software well enough to say with certainty. I don't want to sound ungrateful. What we had, and what we still do have to a lesser extent, was amazing. I wish we could have scaled it, because it was well on its way to being a 40000-user-a-day connected gaming chat network expressed via the in-game chat of Minecraft. Sadly, that's the nature of prototypes and free software. I was willing to work on EiraIRC, but the author... seemed uncomfortable with the idea when we approached them. It's... a strange corner of the world that Minecraft modders live in.

by kbuck 11y ago

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.
  - e12e 11y ago
    I read that more as: "your use case looks like the way people attack our network (and people actually do attack our network). It is too much work to enable your bots to run what amounts to simulated attacks, when what we want is a network for people to communicate with each other". It certainly is a limitation, but any kind of service needs DDOS mitigation.
    - KirinDave 11y ago
      Why did you write this post?
- KirinDave 11y ago
  I am intimately aware of the EiraIRC bugs. I helped diagnose the cause of more than a few that we relayed back to the mod author. Personally, I think that you're describing a lot of limitations that we nearly crashed into with the specific implementations of EsperNet at the time. I think if a more modern system were brought to bear on the problem, they wouldn't exist. But that's all speculation; I don't know EsperNet's current or previous software well enough to say with certainty. I don't want to sound ungrateful. What we had, and what we still do have to a lesser extent, was amazing. I wish we could have scaled it, because it was well on its way to being a 40000-user-a-day connected gaming chat network expressed via the in-game chat of Minecraft. Sadly, that's the nature of prototypes and free software. I was willing to work on EiraIRC, but the author... seemed uncomfortable with the idea when we approached them. It's... a strange corner of the world that Minecraft modders live in.