I can probably work this out myself with a little experimentation... but if someone already knows, I could use a few pointers.

How exactly does bnet decide that you've "Flooded" ?

I've noticed that you can get away with sending small packets quite quickly, but large packets will disconnect you in fairly short order with only two.

However, you arent allowed to send smaller packets (single-letter) at a byte-rate equal to that of a larger one (you can get away with sending one 200 byte packet in one second, but not sending 200 x 1 byte packets in a second, for example).

Anyone know the precise method used to decide?

(I'd prefer replies in english rather than code)

Thanks :)

[quote author=EvilCheese link=board=17;threadid=1249;start=0#msg9315 date=1052318141]
I can probably work this out myself with a little experimentation... but if someone already knows, I could use a few pointers.

How exactly does bnet decide that you've "Flooded" ?

I've noticed that you can get away with sending small packets quite quickly, but large packets will disconnect you in fairly short order with only two.

However, you arent allowed to send smaller packets (single-letter) at a byte-rate equal to that of a larger one (you can get away with sending one 200 byte packet in one second, but not sending 200 x 1 byte packets in a second, for example).

Anyone know the precise method used to decide?

(I'd prefer replies in english rather than code)

Thanks :)
[/quote]You're on the right track, and some experimentation has been done. However, as far as I know, the exact formula remains elusive. Later today I can post the routine I use, which seems to be ok up to a point. My usage almost never stresses it to the point of flooding, except during explicit attempts to do so. It's not perfect, but it works pretty well. :)

One minor thing to try which should help reduce flooding a bit is to limit the amount of outbound automatic traffic you do. For instance, don't respond with "Permission denied" type errors. These can be bad anyway, since someone could drop a massbot on you and have all its instances try a command. Your bot would be shortly overloaded trying to inform all the massbots of their unauthorized status.

I was playing around with Adron's anti-flood algorithm earlier. The reason I asked here is because I'm not sure if that's the best way to approach it.

For example, it assumes a constant allowed rate for individual packets. However, from what I've seen, it's not a rate-dependant detection, but appears to be a cumulative detection with a secondary rate checking aspect.

I'm envisioning the (by packet numbr) flood detection part to work as a counter. Each received packet increments the counter, and then the counter is decreased by 1 every x milliseconds. If the counter breaks a fixed maximum value, you've flooded.

Along with that, there also appears to be a direct byte-rate limit. If your bytes sent over a period breaks a fixed value, you've flooded.

This may be WAY off, but it fits with what I'm seeing.

I'd certainly be interested in seeing your routine. I'll also post what I come up with as soon as I come up with it :)

Edit:A couple of typos. ;)

I seriously doubt that's correct, EvilCheese. Your method would give chat clients a much more forgiving flooding limit - why make it easier for spambots to spam and make it harder for legitimate game client users to chat?

I'd recommend leaving binary-connection-specific aspects out of flooding.

[quote]
Your method would give chat clients a much more forgiving flooding limit.
[/quote]

How so?

'THIS STUFF GOES ON THE FORM
'WHERE WINSOCK IS

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Private Declare Function GetTickCount Lib "kernel32" () As Long
Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
DIM SentBytes
DIM LastTick

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Public Function RequiredDelayMS(ByVal wordlen As Long) As Long
SentBytes = SentBytes - (BytesPerMS * (GetTickCount - LastTick))
If SentBytes <= 0 Then
RequiredDelayMS = 0
Else
RequiredDelayMS = SentBytes / BytesPerMS
End If
SentBytes = wordlen + 134
End Function

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
'place LastTick = GetTickCount()
'where it will be the last thing to
'process.. for me its "SendComplete"
Public Sub winsock_SendComplete()
LastTick = GetTickCount()
End Sub

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
'example of usage
Sleep(RequiredDelayMS(len(message)))

'erm.. one more thing.. the
'Sleep(RequiredDelayMS(LEN(message)))
'goes b4 the actual send takes place

'ieg
Sleep(RequiredDelayMS(LEN(message)))
Send message

'and

BytesPerMS = .06

'i used the first usable digit i found
'.07 will flood out.. so .06 - .07 is
'where the exact variable lies..
'but the smaller the BytesPerMS
'the safer u are.. less likely to flood out

'and

'the safe text send limit for length
'of message is 65. if length is more
'then u will flood out b4 reaching the
'50th send..
'there is a second algorithm involved
'in determining the period of time to
'wait to recover.. but its not worth the
'stinkin hassle. so dont bother