• Welcome to Valhalla Legends Archive.
 

Anti-Flood

Started by c0ol, June 05, 2003, 11:44 PM

Previous topic - Next topic

c0ol

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.

Skywing

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.

c0ol


Tuberload

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.
Quote"Pray not for lighter burdens, but for stronger backs." -- Teddy Roosevelt
"Your forefathers have given you freedom, so good luck, see you around, hope you make it" -- Unknown

Grok

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?

Tuberload

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.
Quote"Pray not for lighter burdens, but for stronger backs." -- Teddy Roosevelt
"Your forefathers have given you freedom, so good luck, see you around, hope you make it" -- Unknown

c0ol

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 ;)