Anope IRC Services
Anope Development => Modules => Topic started by: David Davidson on April 18, 2012, 11:47:29 PM
-
We've been using bs_fantasy_dt (which allows you to add custom fantasy commands and replies) but there's a flooding problem.
Let's imagine you have a command, !command. The reply is "You called?"
Last night in our test channel, someone flooded with !command repeatedly for about 30 seconds. After attempting to keep up with him, the channel bot quit, and seconds later a large services netsplit occurred as services pinged out.
<someone>: !command
<bot>: You called?
<someone>: !command
<someone>: !command
<someone>: !command
<someone>: !command
<bot>: You called?
<bot>: You called?
<someone>: !command
<someone>: !command
<someone>: !command
<bot>: You called?
<someone>: !command
bot has left the channel (*net *split)
The log, which unfortunately I no longer have, simply showed a high amount of latency on services, followed by a ping timeout from services.
Was just wondering how do other fantasy modules avoid this issue? We did some testing and no other fantasy command causes services to split completely after being flooded.
Is there some code we could add to the module to make it either ignore repeated requests like that or else handle them without causing a crash?
Would really appreciate any help you could give us!
-
was this a sustained flood? how many triggers are there in the DB/channel? how many '!command's per second were there?
Chances are most other fantasy modules can more quickly return a result or determine a command is invalid, but because bs_fantasy_dt has more work to do it needs more processing time.. if a flood is sustained that *could* potentially be an issue..
It would help to have much more details though.. normally - if properly configured - clients should fill their sendq and be dropped by the ircd long before they can actually flood anything.
bs_fantasy_dt doesn't have any flood protection of its own, I know that it can be abused to cause floods but reasoned that those should be prevented by the ircd or even the botserv anti-flood, but the ircd is really the best choice here..
as for the split itself, without much more details (at the very least a split reason) it s actually impossible to tell what caused it, and lacking a cause there cannot be a cure..