uhhh, How do u use Grok's Flood Protection in vl doc's. Ive tried using but it never seems to work.
If you're talking about chat, then you've got a problem. My bot has an interesting way of dealing with ban floods. The queue as a base sends every 2500ms, and every other ban it +/- 750ms. Every 15 bans it pauses for 10 seconds. This has yet to drop and I've banned loads nonstop for 30 minutes. So I dunno...you might want to set the ms based on the queue count.
I couldn't get Grok's to work, but this is my Java code (should be easy enough to port it):
private long firstMessage = 0;
private long sentBytes = 0;
private long sentPackets = 0;
private long totalDelay = 0;
public long calculateDelay(long bytes)
{
sentBytes += bytes;
sentPackets++;
long requiredDelay = (sentBytes * perByte) + (sentPackets * perPacket);
if(firstMessage + requiredDelay + totalDelay < System.currentTimeMillis())
{
firstMessage = System.currentTimeMillis();
requiredDelay = 0;
sentBytes = bytes;
sentPackets = 1;
totalDelay = requiredDelay;
return 0;
}
totalDelay += requiredDelay;
long timeSinceFirst = System.currentTimeMillis() - firstMessage;
return requiredDelay - timeSinceFirst + totalDelay;
}
Having a threaded queue sending messages in order is better than calculating a delay . :)
Quote from: DaRk-FeAnOr on July 15, 2004, 08:39 AM
Having a threaded queue sending messages in order is better than calculating a delay . :)
I fail to see how that provides flood protection. Maybe if you'd explain more and provide an example?
If you send too many messages within a short timespan, you get disconnected for flooding, that's what this algorithm is designed to prevent.
This algorithm has nothing to do with protecting your bot from floodbots
Quote from: TangoFour on July 15, 2004, 09:10 AM
If you send too many messages within a short timespan, you get disconnected for flooding, that's what this algorithm is designed to prevent.
This algorithm has nothing to do with protecting your bot from floodbots
And I don't see what flood protection has to do with floodbots :/
Quote from: iago on July 15, 2004, 11:20 AM
Quote from: TangoFour on July 15, 2004, 09:10 AM
If you send too many messages within a short timespan, you get disconnected for flooding, that's what this algorithm is designed to prevent.
This algorithm has nothing to do with protecting your bot from floodbots
And I don't see what flood protection has to do with floodbots :/
I think he said that because Pianka was talking about his flood bot banning thing.
Quote from: DaRk-FeAnOr on July 15, 2004, 08:39 AM
Having a threaded queue sending messages in order is better than calculating a delay . :)
Why would the queue need to be threaded unless you are running multiple bots from the same process? A priority queue data structure is all you need to store the data. Then you need an algorithm to calculate the time between sends (hence what iago posted). Run it all off of some sort of timer and you are set.
Quote from: Tuberload on July 15, 2004, 02:16 PM
Quote from: DaRk-FeAnOr on July 15, 2004, 08:39 AM
Having a threaded queue sending messages in order is better than calculating a delay . :)
Why would the queue need to be threaded unless you are running multiple bots from the same process? A priority queue data structure is all you need to store the data. Then you need an algorithm to calculate the time between sends (hence what iago posted). Run it all off of some sort of timer and you are set.
Mine actually calculates the absolute time, not the delay. But I think the main problem with his queue is that it
doesn't work. And he won't stop bugging me to help him fix it!
Grok's version has an overflow problem. You will need to convert the signed long into an unsigned long (an unsigned long will not fit into a vb long, but rather a vb double)