Valhalla Legends Archive

Programming => Battle.net Bot Development => Topic started by: c0ol on June 05, 2003, 11:44 PM

Title: Anti-Flood
Post by: c0ol on June 05, 2003, 11:44 PM
after sifting through this forum, i didn't find any upto date flood protection threads, so im starting one ;).  Before wasting a bunch of time researching the optimal algorithm(sp?) im wondering if anyone has any comments on it.
Title: Re:Anti-Flood
Post by: Skywing on June 05, 2003, 11:51 PM
After 67 bytes, the amount of delay per message rises to an extremely high, unusable level.  In fact, I proved that it's always faster to split messages at 67 bytes than to send one message over 67 bytes.  Before 67 bytes, the old algorithm mostly holds true -- I gave up with my flood tester after it was still failing to raech 100 sent messages with thirty seconds delay between messages for a 68 byte message.
Title: Re:Anti-Flood
Post by: c0ol on June 06, 2003, 12:08 AM
thanks
Title: Re:Anti-Flood
Post by: Tuberload on June 06, 2003, 12:58 AM
A thirty second delay between outgoing messages seems ridiculous... 67 bytes isn't even really that big of a message.

For a simple example, if I try sending a regular talk message that is 80 bytes it should be broken up into two talk messages, queued then sent? Using a previously determined anti-flood algorithm of course.
Title: Re:Anti-Flood
Post by: Grok on June 06, 2003, 02:20 AM
Nooooo, what he's saying is if sending 100 consecutive 67 byte messages with the minimum delay between each, the delay incurred by attempting to send a 68-byte message is too high to even consider.

At <=67 bytes, you can calculate a delta for each message to wait before sending.

At 68+ bytes, the delta is too high to be of any use on battle.net.

See?
Title: Re:Anti-Flood
Post by: Tuberload on June 06, 2003, 03:52 AM
Yes, thanks for the explanation. Once I do some testing of my own it should be clear.

Once again thank you Skywing and Grok for the information.
Title: Re:Anti-Flood
Post by: c0ol on June 06, 2003, 03:36 PM
hmm after looking at this: http://www.valhallalegends.com/adronfloodprotection.htm, i noticed a typo (or mabe me just being dumb) where (lasttick - tick) is used, lasttick in all cases is going to be a lower number, so that will either be negative or very large depending on the context, i doubt this is what was intended, but even after changing it i still get delay times upwards of 20 seconds after just a few consecutive sends.  here is my perl implementation:

#RequiredDelay function based on Adron[vL]'s C-ish function, value tweaks
#suggested by Skywing[vL] for the new flood protection system
use Time::HiRes qw( gettimeofday tv_interval );
my %queue;
$queue{'starttime'} = [gettimeofday];
$queue{'lasttick'} = 0;
$queue{'sentbytes'} = 0;

sub GetMS {
   return int(tv_interval($queue{'starttime'}, [gettimeofday]) * 1000);
}

sub RequiredDelay {
   my $bytes = shift;
   my ($perpacket, $msperbyte, $maxbytes)  = (200, 13, 600);
   my $tick = GetMS();
   
   if($tick - $queue{'lasttick'} > ($queue{'sentbytes'} * $msperbyte)) {
      $queue{'sentbytes'} = 0;
   }else {
      $queue{'sentbytes'} -= int(($tick - $queue{'lasttick'}) / $msperbyte);
   }

   $queue{'lasttick'} = $tick;
   if($queue{'sentbytes'} + $perpacket + $bytes > $maxbytes) {
      return (($queue{'sentbytes'} + $perpacket + $bytes - $maxbytes) * $msperbyte);
   }

   $queue{'sentbytes'} += $perpacket + $bytes;
   return 0;
}


if anyone can shed any light on to this, please feel free ;)