Valhalla Legends Archive

Quote from: tA-Kane on December 04, 2008, 12:49 AM
even if it's just an anti-idle.

Yeah, I intended to do that already. BUT, I would kick the client if he is hyperactive with anti-idle msgs

Quote from: tA-Kane on December 04, 2008, 12:49 AM
Make sure you have a maximum limit to the amount someone can accrue in the bank.

Good idea, that would solve the kick when idle.

Quote from: tA-Kane on December 04, 2008, 12:49 AM
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.

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 from: tA-Kane on December 04, 2008, 12:49 AM
If requests are going both ways

Fortunately, they don't 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 ?

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

Quote from: tA-Kane on December 02, 2008, 11:11 AM
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).

Hehehe. had to lookup what giggles means at dict.leo.org

Quote from: tA-Kane on December 02, 2008, 11:11 AM
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.

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 Good solution too, thanks that will save me a lot of trouble!

Quote from: tA-Kane on December 02, 2008, 11:11 AM
I suggest looking at the WinSock QOS ..... CUT

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?

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 ?

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.