All right... So I think this feature is already implemented in a bot, but I would like to add it to mine.

The way I see it, if I could store the last user to leave's name and the time they left, then check the next user to join, if the username is the same, then subtract the time that they joined from the time that they left, and if that integer is greater than say 1000ms then it would ban the user, under the assumption that the user is indeed a floodbot...

I think this would be very effecient, as many floods I have seen use double joining at very fast speeds...

So my question, where would I even start to get this result?

Note that if a floodbot is working properly, it will tack a FIN onto the end of its message stream, so that it's actually already logged off by the time you see it enter the channel.  As such, it cannot be banned.

Well then how is it possible that bots like Flawed can use SpamBan or PingBan to ban them? If this is possible, many floodbots must NOT work properly...

And also, Triumph Bot G4 by PunK has that Floodmode that bans on entry, and that can ban floods... So it must be possible, at least to some extent...

So again, how would I go about coding it?

Simple, the latency of the Spammer is higher and the Bot bans them before they leave. Do note the probability of anybot catching a FLOOD BOT with an Automoderation feature (ie SpamBan, Fast Join) is higly unlikely as they were coded purely to keep the peace not from FloodBots but from every day users.

[quote author=FaDeS link=topic=10831.msg102623#msg102623 date=1110073191]
Well then how is it possible that bots like Flawed can use SpamBan or PingBan to ban them? If this is possible, many floodbots must NOT work properly...

And also, Triumph Bot G4 by PunK has that Floodmode that bans on entry, and that can ban floods... So it must be possible, at least to some extent...

So again, how would I go about coding it?
[/quote]

Let me give you a piece of advice. Floodbots ARE 99% IMPOSSIBLE TO BAN. How do some bots ban them? Quite simply because they floodbot is on a shitty connection either because of a slow proxy or a shitty connection by the end user altogether. Now bots such as Flawed or whichever other shitty bot you decide use are able to ban them because they simply get lucky. Now instead of saying how they are able to ban them, ask how come they don't ban all of them. Think about it, the bot is lucky enough to ban the bot maybe once or twice and maybe again 30 minutes later? Now if I was the one "flooding" I would have at least 100 cdkeys attached. You really think you're going to get all 100? The answer is no, you will fail and would've have wasted bandwidth at that.

Now if you still don't believe me, Go ahead and load your "flawed" bot and I'll load a flood bot and we'll see who wins and who "owns." infact you don't even need me to test this, do it yourself, I gurantee you won't do it.

You said:
And also, Triumph Bot G4 by PunK has that Floodmode that bans on entry, and that can ban floods

When else would you be able to get an ACTUAL successful ban if possible at all out? During the time it spams? It's probably already logged off by the time you recieve it.

They way you described to ban floodbots is generally how it is done without a timer and upon a user joining.

The best way to get around floodbots is to not interact (display, ban, etc.) any user who is in the channel for less than a time limit; say, 300ms.  I find it works quite well when implemented properly.

Ok, well I solved the problem myself... Anyways, to keep an old thread running, why are you all so down on the floodbanning system? I honestly think there must be SOME way to ban a floodbot... Maybe it would be a bit better if you took all your negative comments about my BAD idea,  and use that energy to come up with a GOOD idea? I don't know... Food for thought I suppose...

Because there is no 100% way to ban a floodbot, its just not possible, and maybe when you realize that you can start following iago's idea of ignoring them rather than waste your time hopelessly trying to ban them.

The only real way to "win" the floodbot war is to prevent it from happening in the first place. Since server-side options aren't existant (*cough*stupidblizzard*cough*), the only way is to keep your channel with a low profile and not start "wars" with people.

'wars'. Haha! So why do people flood a channel when they could do the much more meaningful 1v1? Thats more like a 'war'.

As Kp said in his original post:

[quote]Note that if a floodbot is working properly, it will tack a FIN onto the end of its message stream, so that it's actually already logged off by the time you see it enter the channel.  As such, it cannot be banned.[/quote]

To translate that the english, he said a floodbot working properly will:
-Connect
-Send messages
-Disconnect

At the SAME TIME.  Literally, all three events will arrive to you in the same packet.  Because this is happening at the SAME TIME, it is impossible to actually ban it.  By the time you've seen it, it's already too late.  And before you see it, it's too early. 

Since, like iago said, all events arrive in the same packet, I think it's easiest to just filter out any events from a user when they join AND leave the channel in the same clumped packet.

[quote author=FaDeS link=topic=10831.msg102635#msg102635 date=1110079911]
Ok, well I solved the problem myself... Anyways, to keep an old thread running, why are you all so down on the floodbanning system? I honestly think there must be SOME way to ban a floodbot... Maybe it would be a bit better if you took all your negative comments about my BAD idea,  and use that energy to come up with a GOOD idea? I don't know... Food for thought I suppose...
[/quote]

Because there is no system. Banning 1% of the total amount of floods is hardly a good method. You're sad if your ego needs to be greatened by feeling like you "owned" a mindless drone that joins and leaves.

As for putting forth energy of thinking of a way to ban them, we have all done that and in the end have noticed that we just wasted our time in something we could have easily filtered and gone on with life. Did you ever think that maybe all these people are telling me the truth or do you think it's some sort of conspiracy?

[quote author=FaDeS link=topic=10831.msg102635#msg102635 date=1110079911]Ok, well I solved the problem myself... Anyways, to keep an old thread running, why are you all so down on the floodbanning system? I honestly think there must be SOME way to ban a floodbot... Maybe it would be a bit better if you took all your negative comments about my BAD idea,  and use that energy to come up with a GOOD idea? I don't know... Food for thought I suppose...[/quote]

Every few months some clueless individual (usually a VB newbie, btw), brings this up.  Every time they've failed to read the old thread where we hashed this out, which included a nice technical discussion of why this simply cannot work.  If you'd read that thread, we might've been more sympathetic here.  If you read it and don't understand it, please feel free to ask questions here about what you didn't understand.  In the interim, you're not contributing anything new to a field we've declared solved a long time ago.  For instance, you claim to have solved it on your own.  If it's a good solution, post it so we can critique it.  Otherwise, please remember that we've been here for a long time and floodbots are old news to many of us.

[quote author=iago link=topic=10831.msg102629#msg102629 date=1110077605]
The best way to get around floodbots is to not interact (display, ban, etc.) any user who is in the channel for less than a time limit; say, 300ms.  I find it works quite well when implemented properly.
[/quote]

This works beautifully in StealthBot.

[quote author=Stealth link=topic=10831.msg102712#msg102712 date=1110158863]
[quote author=iago link=topic=10831.msg102629#msg102629 date=1110077605]
The best way to get around floodbots is to not interact (display, ban, etc.) any user who is in the channel for less than a time limit; say, 300ms.  I find it works quite well when implemented properly.
[/quote]

This works beautifully in StealthBot.
[/quote]

What do you use as a time limit, by default? I think I used 300ms, but I have very little experience with flootbots (that, or my protection is so good I don't see them..)

300ms is a little low, in my experience.  I recommend at least 500ms.

[quote author=Kp link=topic=10831.msg102727#msg102727 date=1110171957]
300ms is a little low, in my experience.  I recommend at least 500ms.
[/quote]

300ms is StealthBot's default, but it is customizable (or can be disabled entirely) through a config.ini hack. The only complaint that I have received about it is that it eats whispers at times because the threshold is applied to incoming whispers without taking into account the originating account name on the whisper -- two whispers from two different users within 300ms of each other will cause the second one to be dropped. This is, as Microsoft says, "by design", to prevent "whisper flooding" -- but I may change it in the near future.

While I can see the value of an anti-whisper-flood mechanism, it sounds like a bug that your anti-floodbot code is serving that purpose. :)  If you redesign it, I'd suggest separating out the logic so that users can have an anti-whisper-flood configured (or even disabled) independently of the anti-floodbot logic.

[quote author=Kp link=topic=10831.msg102733#msg102733 date=1110176003]
While I can see the value of an anti-whisper-flood mechanism, it sounds like a bug that your anti-floodbot code is serving that purpose. :)  If you redesign it, I'd suggest separating out the logic so that users can have an anti-whisper-flood configured (or even disabled) independently of the anti-floodbot logic.
[/quote]

Not so much a bug as the wrong kind of laziness. I'll do that.

On mine, I keep a hashtable of all the users who are on their 300ms delay.  If a user enters the channel, whispers me, and leaves, I won't see it because it queues the whisper to be seen (after the user has been in the channel past the delay).

Which brings up another question, if somebody enters the channel and says something within 300ms, then remains in the channel, do you eventually see what he says? It took me awhile to get that working right (and I don't really like the logic I used to do it).

I settled on letting events get slightly reordered, so my logic is that events from users who're visible to me are passed through immediately, and all events from users who aren't yet displayed (that is, have joined within the delay window), are queued.  If the user stays in channel long enough, all events for him are dequeued and I see his join + any talks he's made.  If he leaves within the window, I wipe all his events and never process them.

If the join event contains the latency of the user, why stick with a set constant number as opposed to the latency of the user?

Also, for modular design, do you think it's better to have these users filtered through the connection mechanism or through the user interface?

[quote author=iago link=topic=10831.msg102766#msg102766 date=1110216661]
Which brings up another question, if somebody enters the channel and says something within 300ms, then remains in the channel, do you eventually see what he says?
[/quote]
Nope, not on stealthbot.

[quote author=MyndFyre link=topic=10831.msg102785#msg102785 date=1110243186]
Also, for modular design, do you think it's better to have these users filtered through the connection mechanism or through the user interface?
[/quote]

Neither. I'd have something inbetween to do it. If that's not possible, then UI: the connection mechanism shouldn't hide things from your application logic, imo. I'd have something like Connection -> Processing -> UI, and do filtering in Processing.

For plugin stuff, I have two levels for events, RawEvent which takes care of filtering and delays, and then Event, which is things like talk(), whisperFrom(), etc.  Some Raw handler has to explicitly call the Event handler.

And I do mine the same as kp -- I settle for re-ordering and broken timestamps.

I'm pretty sure FaDeS is the person I'm thinking of, because that technique of banning floodbots is the exact same thing I recently told someone. Of course it still isn't going to catch anything unless the floods are lagging. I had another idea, if a user is flooding on either their own IP (I know it won't last long) or very fast proxies, then if you were to determine the interval between each flood, and send a ban message at the proper time (of course they would need to be using only one account for the flood), could you then ban them? I'm asking this because I once banned a floodbot by sending a ban message for that name right before it connected. Does anyone think this is capable of working successfully?

[quote author=Yegg link=topic=10831.msg102883#msg102883 date=1110314603]
I'm pretty sure FaDeS is the person I'm thinking of, because that technique of banning floodbots is the exact same thing I recently told someone. Of course it still isn't going to catch anything unless the floods are lagging. I had another idea, if a user is flooding on either their own IP (I know it won't last long) or very fast proxies, then if you were to determine the interval between each flood, and send a ban message at the proper time (of course they would need to be using only one account for the flood), could you then ban them? I'm asking this because I once banned a floodbot by sending a ban message for that name right before it connected. Does anyone think this is capable of working successfully?
[/quote]

https://davnit.net/bnet/vL/phpbbs/index.php?topic=3231.0