30.10.2008 11:37
A tool I needed to stop hammering our COD2 gameserver with StatusResponse UDP packets.
The gameserver gets hammered constantly by hundreds of players each second, because they use so-called 'game managers' like HLSW or All Seeing Eye. Programs like this often send hundreds of UDP requests to get the server status - map, gametype and playerlist. That alone would be OK, but they keep refreshing the lists like every 10 seconds! Imagine a thousand of users choosing where to connect. Or even worse, those who left the tool open and leave the computer physically.
Naturally, our slow network line or weak CPU didn't manage to work it out without problems. The game lagged.
So my aim was to differentiate between gameplay packets and those of HLSW-like tools. It wasn't easy, because the game uses the same UDP port for all communication. I needed to examine the content of packets somehow and filter out the bad guys.
For this to work, you need a linux kernel with IMQ and U32 support and appropriately patched IPtables.
The script I wrote sends all INPUT and OUTPUT game packets [UDP, 28960] to IMQ virtual device. Then TC's plugin U32 scans their content to match specific content. Actually the bad packets contain the words getstatus and statusResponse inside, so finding this was quite easy; maintaining the syntax U32 wanted to hear was a little tricky. Matched packets are redirected to a class, that we designated as shaped. All other packets must come through instantly to keep ping low and minimize lagging.
So now we have set up a shaper, that shapes packets from HLSW-like tools. And unforutnately also game's own serverstatus packets. We wanted to keep some data flowing, so users would see the server as online in the game menu. So we need to balance it.
My first try was to shape it 3/3 kbit/s [down/up]. It seemed successful, becaused the game lagged no more. Another day no players came. I began to think people actually are dependant on those tools, as I saw them thinking the server was offline or that they were banned. They had no idea how to connect to the game, except using HLSW-like tools. Some I've told "use the game menu --> favorites", but the server was more empty each day.
So I raised the limits to 20/20. There still are some lags, but it sure is more playable than without it.
Now that I think of it, the Upload should be large and we should only limit Download a lot because of UDP 'deliver now or never' behaviour.
At the time of writing this, I'm testing 10/50 on Kafemlynek.
The gameserver gets hammered constantly by hundreds of players each second, because they use so-called 'game managers' like HLSW or All Seeing Eye. Programs like this often send hundreds of UDP requests to get the server status - map, gametype and playerlist. That alone would be OK, but they keep refreshing the lists like every 10 seconds! Imagine a thousand of users choosing where to connect. Or even worse, those who left the tool open and leave the computer physically.
Naturally, our slow network line or weak CPU didn't manage to work it out without problems. The game lagged.
So my aim was to differentiate between gameplay packets and those of HLSW-like tools. It wasn't easy, because the game uses the same UDP port for all communication. I needed to examine the content of packets somehow and filter out the bad guys.
For this to work, you need a linux kernel with IMQ and U32 support and appropriately patched IPtables.
The script I wrote sends all INPUT and OUTPUT game packets [UDP, 28960] to IMQ virtual device. Then TC's plugin U32 scans their content to match specific content. Actually the bad packets contain the words getstatus and statusResponse inside, so finding this was quite easy; maintaining the syntax U32 wanted to hear was a little tricky. Matched packets are redirected to a class, that we designated as shaped. All other packets must come through instantly to keep ping low and minimize lagging.
So now we have set up a shaper, that shapes packets from HLSW-like tools. And unforutnately also game's own serverstatus packets. We wanted to keep some data flowing, so users would see the server as online in the game menu. So we need to balance it.
My first try was to shape it 3/3 kbit/s [down/up]. It seemed successful, becaused the game lagged no more. Another day no players came. I began to think people actually are dependant on those tools, as I saw them thinking the server was offline or that they were banned. They had no idea how to connect to the game, except using HLSW-like tools. Some I've told "use the game menu --> favorites", but the server was more empty each day.
So I raised the limits to 20/20. There still are some lags, but it sure is more playable than without it.
Now that I think of it, the Upload should be large and we should only limit Download a lot because of UDP 'deliver now or never' behaviour.
At the time of writing this, I'm testing 10/50 on Kafemlynek.
![[Image: kavove-zrnka-lajna.jpg]](https://ashus.ashus.net/images/custom/kavove-zrnka-lajna.jpg)
Coffee phreak!