Flood Bot Filtering Discussion

[Archangel]

Well before starting doing this i want to c whats the best way for doing this, well any suggestion?

[The-FooL]

Or just don't connect to battle.net at all.

Seriously though, you could try keeping a count of the number of users that join your channel(or the number of messages that are said).  Decrease the number over time.  If the number goes to high, temporarily ignore all joins or talks.

[tA-Kane]

Seriously though, you could try keeping a count of the number of users that join your channel(or the number of messages that are said).  Decrease the number over time.  If the number goes to high, temporarily ignore all joins or talks.

That might work for inactive channels, but for channels that get a lot of activity, that could easily get whacko.

Instead, a better way would be to delay the parsing of the join event for half of a second (or even a quarter of a second if you wish... but most users who "channel surf" on Battle.net are in a channel for around a second before moving on). If the user leaves before that time is up, then they're considered flooding.

This is quite useful because in that short amount of time, it's (or should be) VERY easy for the bot with ops to ban them. So it would be hard to get around the flood protection and still not get banned.

[iago]

Another thought: wait for your own ping time to pass and then process.  That way, you know there's time to send a ban.

[Adron]

Shouldn't you wait for the op bot's ping time?

[iago]

I assumed we were talking about an op-bot

[Adron]

Couldn't an op bot just not display the data of any user it was going to ban?

[iago]

I didn't say displaying data, I said sending a ban.  I'm talking about not letting modbots get bogged down by bans.  I don't care whether or not it's displayed.

hmm, perhaps the person who started this thread could clarify if we're talking about mod-bots or chat-bots, but in any case, you would wait till your own ping time before taking any actions

[Lenny]

Wouldnt you also have to account for the server's own ping to relay the ban command to the other server, unless  you're connected to the same server that the floodbot connected to...

[Stealth]

Enqueue all inbound events -- then you have control over which ones are displayed. Duplicate or similar events, as well as messages sent too close to each other, can be dropped.

[iago]

Wouldnt you also have to account for the server's own ping to relay the ban command to the other server, unless  you're connected to the same server that the floodbot connected to...

Not if you ARE the ops server.  I don't care about chat clients, the people using them can suffer, I'm talking about the actual bot looking after the channel.

[Adron]

But if you always delay the ban by that amount, they can redesign their bots to account for that and spam a bit more...

[iago]

But if you always delay the ban by that amount, they can redesign their bots to account for that and spam a bit more...

I was thinking that, actually.  Perhaps you can send the ban, but check back in [ping] to see if it's still there; if not, it doesn't bother with it anymore.  As long as you have apt flood protection, that wouldn't hurt.

When I say not bother with it anymore, I mean displaying the event/updating log/etc.

[Lenny]

What I meant was, doesnt the server the floodbot is connected to perform the ban?

If the ops weren't on the same server, the ban would be relayed to the server which the floodbot connected to in order to ban.

[Soul Taker]

What I meant was, doesnt the server the floodbot is connected to perform the ban?

If the ops weren't on the same server, the ban would be relayed to the server which the floodbot connected to in order to ban.

Bans are by CD-Key though, so the damage would be done, I think.