Does anyone have any code or logical implementation of having the bot ignore rejoin spammers?  The ultimate idea is to prevent the bot from attempting to ban these rejoin spammers with normal automoderation modes without having to disable them manually (or automatically).  The reason would be that rejoin spammers can rarely be banned, and even if you are capable of banning them you won't get them each time they do a spam, it'll take several tries (from what I've seen), and ignoring them will relieve the queue of unecessary ban attempts.

Delay the outgoing que for the automoderation features, and remove any items from the que for that user if they are flagged as a rejoin spammer.  Just check time between join/leave.

That seems like a bad way to do it; I heard there's an implementation out there (or that somebody did) that detects whether it receives a certain number of chat events in one TCP packet.

I use a static String and Long in my UserJoin subs and check the username joining vs the last username that joined, as well as the delay, by using GetTickCount(), since they last joined.  I filter out and ban users who join repeadetly within 750ms or so.

I was referring to a way to prevent automoderation bans from being sent when the floodbots join, filtering them is easy.  You can always check the length of the data recieved.

Well, for that I use a StoreVal() function (which I can post if you want it) and store the username and tick on join in there, then compare them vs values set in UserLeave.  If the usernames match and the difference in GTC - JoinTick is enough to fire the ban, I simply remove the ban call from my queue.

[quote author=Mephisto link=topic=9815.msg91428#msg91428 date=1102460669]
That seems like a bad way to do it; I heard there's an implementation out there (or that somebody did) that detects whether it receives a certain number of chat events in one TCP packet.
[/quote]Then do it that way if you want. If the chunk of data you receive has a join, talk and leave packet, ignore all of them.

[quote author=Eibro[yL] link=topic=9815.msg91493#msg91493 date=1102486621]
[quote author=Mephisto link=topic=9815.msg91428#msg91428 date=1102460669]
That seems like a bad way to do it; I heard there's an implementation out there (or that somebody did) that detects whether it receives a certain number of chat events in one TCP packet.
[/quote]Then do it that way if you want. If the chunk of data you receive has a join, talk and leave packet, ignore all of them.
[/quote]

How do you check for that?

Haven't tested yet but check the different offsets in your buffer to see which events you have in that one TCP packet.

Note that if you were to suddenly encounter a lag spike, it could easily cause you to ban an innocent user so I'd make sure that there aren't any more than 1 or 2 non-related packets in that stream before attempting to ban the user.

[quote author=LoRd[nK] link=topic=9815.msg91531#msg91531 date=1102538596]
Note that if you were to suddenly encounter a lag spike, it could easily cause you to ban an innocent user.
[/quote]

Lord what's a way you use to check for combined packets such as join and leave and talk or simply just join and leave ones?

[quote author=Networks link=topic=9815.msg91543#msg91543 date=1102542661]
[quote author=LoRd[nK] link=topic=9815.msg91531#msg91531 date=1102538596]
Note that if you were to suddenly encounter a lag spike, it could easily cause you to ban an innocent user.
[/quote]

Lord what's a way you use to check for combined packets such as join and leave and talk or simply just join and leave ones?
[/quote]

If the length of the stream received is larger than the length specified in the first packet's header, then loop through the packets, handling only those that apply.

Personally, I feel that if the user is not spamming, then he is not creating a problem, so I'd check for the same things Eibro mentioned (user: join, talk/emote, and possibly leave events within a single stream or user defined amount of time).

It occured to me that every time you receive data from Battle.net in a TCP stream that you could check the data you receive for a join & spam & leave event, and if it's true then have an automoderation mode which scans for this sort of event and immediately ban that user; this seems like a logical method to give your bot some sort of chance to ban rejoin spammers as the bot will not process the unecessary packets but get straight to banning the user.

The easiest way is to flush the queue of ban commands for user X when you see user X leaving the channel. If you want complete suppression of bans of such users, do it in combination with always queueing bans and sending from queue only after all commands in a packet have been processed.