Hello guys,

I did read a lot here already. I somewhere read in your wc3 protocol documentation about the timeout technique that blizzard uses to detect and kick out spamming.

I am actually developing a game with a masterserver and want to build something similar in to avoid an overload of the server.

My question to you is if it is actually possible to have "little" anti-spam timeouts when using the TCP protocol, as I did read somewhere else that the TCP protocol itself kind of buffers the messages up to 200ms. This would falsify a lot of (time-based) measurings, and this kind of explains all my problems trying to implement such a method.

Do the people here having already dealt with this have any useful hints or comments to me on how accomplish something like this?

Thanks in advance for your time.

Edit:
More info: One of the problems I encountered, was that the server got a few packets nearly at the same time, even if they were sent out in a 100ms timelapse from the client code. This seems logic to me due to the fact that the TCP protocol says that the client may "collect" outgoing packets up to 200ms and then send them all at a time.

Pompei2, if you've got time-critical messages being sent over TCP, you'll need to disable the nagle algorithm. There's plenty of helpful hints on google for that.

I'm not familiar with WC3's timeout mechanism to which you're referring, but I would like to point out that doing time calculations based solely on network activity (unless I'm mistaken, that appears to be what you're asking about) is a bad idea in most situations. I suggest you include your own timestamps and have a timeout value if you really need to check the difference between different things; unless you're specifically monitoring network topology or congestion, chances are that your timings on the receiving end will easily get messed up just by normal network activity such as network congestion and temporary router failure.

I don't think that the 200ms buffering should affect your anti-spam, messages coming 200ms too late shouldn't have a huge impact. The only time you'll notice this is in times of extremely high latency where a bunch of packets are buffered and re-sent.

Kane is right that disabling the nagle algorithm is good for time-sensitive stuff (it'll ensure that packets are sent/received right away), but it's generally a bad idea to do it for long periods of time.

Thank you for your answers so far.

So, what I want to do is not a good idea (at least to do it for the whole time of a game). At least, I learned that it's possible to disable that algo :)

So, could you make me any suggestions on how to implement a sort of anti-spam system ? What I have is my game-server that gets requests (from game-clients) and then sends an answer for every request. I want to avoid someone writing a simple client that sends like 100 req/sec, start a few of them and then DoS my server. I'd rather like to detect such behaviour and kick every client out that does so.

A "normal" client would send a few requests per second (one to five or so)

Do you have any suggestions ?

Checking against network flooding is one of those situations that it's fine to use time calculations based solely on network activity (*giggles*, I was trying to get you to think). Just make sure to include into your calculations (or moreover, your punishments) the fact that it might not have been the client's fault that a flood was detected. One of the easiest ways to do that is to allow for "burst" traffic when you receive no traffic for X amount of time.

I suggest looking at the WinSock QOS information here, it allows for burst traffic during low network activity and a constant amount of expected traffic. In particular, I suggest you look at TokenRate, TokenBucketSize, and PeakBandwidth.

I'm not completely familiar with the workings of WinSock's QOS stuff as I have never used it myself. Therefore if it was me, I would create various tests to ensure that WinSock's QOS functionality is reliable even if someone writes a third party client specifically to avoid your QOS. If that fails (or if you can't use API which is specific to WinSock), then I would simply use the QOS information as a guideline for designing my own QOS-like functionality... which appears to be what you're asking.

[quote author=tA-Kane link=topic=17714.msg180617#msg180617 date=1228237902]
Checking against network flooding is one of those situations that it's fine to use time calculations based solely on network activity (*giggles*, I was trying to get you to think).[/quote]
Hehehe. had to lookup what giggles means at dict.leo.org ;D

[quote author=tA-Kane link=topic=17714.msg180617#msg180617 date=1228237902]
Just make sure to include into your calculations (or moreover, your punishments) the fact that it might not have been the client's fault that a flood was detected. One of the easiest ways to do that is to allow for "burst" traffic when you receive no traffic for X amount of time.[/quote]
Hmmm very good point I did not think of that at all! I think without you, I would have implemented a simple algorithm and then wondered why i get a lot of spam alerts when testing it trough the internet in contrast to the LAN :P Good solution too, thanks that will save me a lot of trouble!

[quote author=tA-Kane link=topic=17714.msg180617#msg180617 date=1228237902]
I suggest looking at the WinSock QOS ..... CUT [/quote]
Did not know about this. Looks quite interesting although it seems to be used to maintain a solid connection, not to limit a connection, I will likely use similar concepts. I can't use this because the game and server have to work on Linux too.

My question now would be if what I want to do is the correct road to go. Does anyone know how other games/servers protect themselves from being killed by some machine-gun-like-spamming clients ? Aside from buying a supercomputer with fiberglass connection  ;)

Right now I would make an algo that somehow adds up points to a "bank" as long as he doesn't get any message and then take points out of that bank as soon as he gets messages, (dependent on message type/size). When the bank reaches some negative value, first warn him then kick him out. Is this a good way to go ? Does someone see obvious (or subtle) problems with this ?

Thanks again for your time. Any suggestion/critique is very welcome!

Edit: just so you know what it is about: It is a "master-server" for a wc3-like game. The server handles player accounts (with properties, possibility to get properties from other players) chatting within multiple rooms and a list of games, but it does not handle a game! (wc3-like, again). Thus a delay of up to 500 ms will hardly be noticed by the player anyways => delay is not crucial. But it is possible to get a bunch of request very quickly in a row (get the status of every player in the channel, for example). Latter would be tolerated by the "banking" system I describe above, right?

I would figure that as a minimum, your protocol should expect a message once every 30 seconds, even if it's just an anti-idle. If you don't receive anything for 90 seconds, then remove the client as a dropped connection.

As far as whether or not it's the "proper" way to do it... well, each person might have a different idea. This isn't the be-all-end-all solution, and I doubt there ever will be.

Adding points up to a "bank" should be fine. Make sure you have a maximum limit to the amount someone can accrue in the bank.

At what point would you kick him out? Keep in mind that if the bank goes negative, chances are that it might go further negative before going positive.

Latter should be tolerated by the banking system, as long as you're not doing a lot of communication with that client over a short period (eg, constantly requesting it to send a list of players in the channel). If you do that, then perhaps you might automagically give some bank credit for the expected reply(ies).

If requests are going both ways (client requests something from server while the server can independently request something from the client), then it might be an idea to have client->server replies not count against the bank. Then the bank system would only detect floods which you didn't cause. To do that properly though, you'd have to make sure that you know ahead of time how many messages the client is going to send. Additionally, you'd have to kick the client if it starts sending extraneous replies (replies to requests for which you did *not* send). This particular idea would be extra work and extra complication though, so weigh it accordingly.

Hope this helps.

[quote author=tA-Kane link=topic=17714.msg180659#msg180659 date=1228373394]
even if it's just an anti-idle.
[/quote]
Yeah, I intended to do that already. BUT, I would kick the client if he is hyperactive with anti-idle msgs :)

[quote author=tA-Kane link=topic=17714.msg180659#msg180659 date=1228373394]
Make sure you have a maximum limit to the amount someone can accrue in the bank.
[/quote]

Good idea, that would solve the kick when idle.

[quote author=tA-Kane link=topic=17714.msg180659#msg180659 date=1228373394]
At what point would you kick him out? Keep in mind that if the bank goes negative, chances are that it might go further negative before going positive.
[/quote]
Hmmm yeah that's a good question. Maybe if I give every client some "startup points" when they connect, I could just set a hard limit at 0, send a warning message if he passes that and then kick him out if he goes belong 5 or 10 (number to test).
Or I would make it dependent on the slope of the bank-credit curve, if the slope falls down too hard, kick. I think it needs some testing to find out which is better.

Good point with the auto-credit too.

[quote author=tA-Kane link=topic=17714.msg180659#msg180659 date=1228373394]
If requests are going both ways
[/quote]
Fortunately, they don't :D Just the server sends a message to the client from time to time (when the client gets a chat message), but awaits no answer.

I think I will look into some open source game servers to see what they do (if they do something).

Anyone knows how apache protects itself from DoS, if it does ? or does it just expect to get enough CPU all the time ? :P

Interesting discussion I think. Learned a lot already.

BTW, why doesn't your homepage get up again ? I remember there were very interesting things.:

This webpage is under construction

Come back later

Last Updated: December 14, 2002

Unfortunately, I don't know much about the internals of apache.

I guess the webserver broke or something, it definitely was working in 2004 / 2005. Oh well, the main webpage wasn't really used much anyways if I remember correctly.