/who Problem

[Skywing]

... they want to ban all users who are in a channel other than the one in which the bot presently resides.  Why such a waste of queue space is desired is beyond me, however.

This is what I said when I was asked to include a sweepban feature in my bot. Naturally, I refused. However, due to popular demand, I added a very simple scriptable version that was disabled by default (note how all of the code is commented out).

Apparantly 'sweepban' is effective against flooders and spammers. I don't see how this is effective at all as bans go by cd key and not IP, but many users have figgured out that a simple alteration of the code to make it 'sweepsquelch' is very effective.

All of this to me is just fluff. The way I deal with flooders is to check if someone triggers too many concurrent 0x0F packets in a short enough time to be considered a flooder. If a flood is detected, the bot goes into lockdown mode for 60 seconds. Lockdown mode will ban any unrecognized user upon joining the channel.

Something to consider:
So, the way for somebody to remove an operator running your bot program is to first, come in the channel and spam, and then do joinfloods?

Be careful when implementing this kind of automated security defense, lest it become a vulnerability in it's own right.

[Camel]

The bot flushes its queue as soon as it gets a 'That user is not logged on.' message. Because the bot stays in lockdown mode for 60 seconds, it is free to immediately ban the next floodbot.

I'm not sure if this is a solution to your proposal as I was somewhat unclear on what you were saying; reply again if it isn't.

[UserLoser]

The bot flushes its queue as soon as it gets a 'That user is not logged on.' message. Because the bot stays in lockdown mode for 60 seconds, it is free to immediately ban the next floodbot.

If I'm understanding this correctly, this is where a priority queue comes in

[TriCk]

... they want to ban all users who are in a channel other than the one in which the bot presently resides.  Why such a waste of queue space is desired is beyond me, however.

This is what I said when I was asked to include a sweepban feature in my bot. Naturally, I refused. However, due to popular demand, I added a very simple scriptable version that was disabled by default (note how all of the code is commented out).

Apparantly 'sweepban' is effective against flooders and spammers. I don't see how this is effective at all as bans go by cd key and not IP, but many users have figgured out that a simple alteration of the code to make it 'sweepsquelch' is very effective.

All of this to me is just fluff. The way I deal with flooders is to check if someone triggers too many concurrent 0x0F packets in a short enough time to be considered a flooder. If a flood is detected, the bot goes into lockdown mode for 60 seconds. Lockdown mode will ban any unrecognized user upon joining the channel.

Something to consider:
So, the way for somebody to remove an operator running your bot program is to first, come in the channel and spam, and then do joinfloods?

Be careful when implementing this kind of automated security defense, lest it become a vulnerability in it's own right.

Ive also added "Sweeptype" cmd to my bot, it can either auto-add the users to a database for later use, or squelch/ban users... It seems to work all good...