Page 1 of 1

Correct management of dropped packets

Posted: 13 Dec 2007, 16:45
by preecep
I am seeing dropped packets occuring for a number of players (a small percentage). This, of course, can break games if the messages are crucial to the game's function.

Should I try to program around this problem or should I just disconnect players when a dropped message is detected?

If the former, is there 'best practice' for handling dropped / late packets? I don't want to reinvent the wheel here :)

Posted: 13 Dec 2007, 17:29
by Lapo
Hi,
starting from version 1.5.9 we have introduced the following settings for handling dropped packets:

Code: Select all

<ClientMessagQueue>
   <QueueSize>120</QueueSize>
   <MaxAllowedDroppedPackets>10</MaxAllowedDroppedPackets>
</ClientMessagQueue>


The QueueSize parameter indicates how big is the queue that the server reserves for each connected client.
MaxAllowedDroppedPackets sets the tolerated amount of dropped packets.

You can experiment with these values until you find the best settings for your type of applications.
Usually the queue size can be a value between 60 and 150 and if you want immediate disconnection when the first packet is dropped you should set the max allowed to 1

Posted: 18 Dec 2007, 19:41
by Kicksome
Is there a way to disable this option? I've having problems with the admintools.swf disconnection when I have a lot of users logged on creating lot of different rooms. Not sure if it's related but I didn't have that problem in pre-1.6

Posted: 18 Dec 2007, 22:46
by Lapo
As said in the earlier post this exists from 1.5.9
There's no way to disable this, and you shouldn't disable it. You can use a very high value if you think your app won't suffer from dropped packets, but a certain point a very slow and sloppy connection should be terminated.

Additionally the queue size allows you to configure the user queue size as appropriate for your game/chat/mmo etc...

Posted: 29 Dec 2007, 15:11
by Kicksome
The problem I have is the Admin tool disconnects every few seconds when I have a lot of people on (it seems like this is due to dropped packets - when I increase the value it stays connected longer). It also doesn't show when a room is created like the old version - you have to go to another tab then click on Zone Browser again to have the new room show.

This wasn't the case with the old Admin tool. Not sure exactly what has changed or what options I need to enabled to make it act more like the old admin tool.

Posted: 30 Dec 2007, 18:18
by Lapo
The problem I have is the Admin tool disconnects every few seconds when I have a lot of people on (it seems like this is due to dropped packets - when I increase the value it stays connected longer).

What settings are you using for the dropped packets?

It also doesn't show when a room is created like the old version - you have to go to another tab then click on Zone Browser again to have the new room show.

This feature was not touched in the new version and we're not aware of any similar problem with the admin tool.
There's probably something else going on. If you have so many dropped packets that could be the cause of the misbehavior

Posted: 07 Jan 2008, 03:03
by preecep
I was thinking that it would be nice if SFS had dropped/delayed/out of order packet recovery built in. I am trying to build it myself but surely my efforts will be duplicated for other developers... and it seems a standard problem in multiplayer games.

Posted: 07 Jan 2008, 07:04
by Lapo
Dropped Packets: a way to enhance the dropped packet handling is to set a priority level to each packet. This could be done programatically: a packet is created with a default value (let's say 5 in a scale from 1 to 10) but the developer can change it in order to specify if it's more or less important. We're thinking about adding this in a future release.

This way the "packet-dropper" can use a smarter logic and try to get rid of the low-priority ones.
Btw, even without this feature it is possible to handle the problem by carefully setting the user queues and increasing the JVM Heap appropriately.

Delayed Packets: this one depends alot on the application that is running. A chat and a turn based game won't suffer too much but a real-time game of course will. Based on the type of real-time game you have a number of options like skipping frames, interpolate an animation from the last-know position etc...

Out of order Packets: this one is impossible. SmartFoxServer uses TCP connections which guarantee the delivery and correct order of each packet.

Posted: 12 Jan 2008, 00:34
by preecep
thanks for reply

You seem to indicate that dropped packets are caused by the user queues, is that the only way a dropped packet can occur? ie Will TCP guarantee that every packet will reach its destination ?

What causes a user queue to fill up and drop packets? We get a quite regular (but still quite rare) occurance of single messages not being sent from the flash client to the server. Could a user queue in its default configuration cause such a problem? (as you may have guessed, I have no idea how to configure the queues, or what each setting might do)

One more question, what happens client side if the game is using 100% processor and smartfox messages are coming in. Do they get delayed because the flash player is at 100% cpu? Might they even get dropped?

Posted: 14 Jan 2008, 10:34
by Lapo
You seem to indicate that dropped packets are caused by the user queues, is that the only way a dropped packet can occur? ie Will TCP guarantee that every packet will reach its destination ?

Yes. Packets are dropped to save the server from exploding when too much data is queued for later delivery until the network is congested/slow.

Without this mechanism you would end up queuing up messages until you eventually fill all the available heap memory and crash the Server loosing all connections... with this perspective you can see why dropping packets is not as evil as loosing the service.

What causes a user queue to fill up and drop packets?

As mentioned before... general lack of bandwidth, client connection slowness, too high message frequency etc...

We get a quite regular (but still quite rare) occurance of single messages not being sent from the flash client to the server.

You should make sure that is not programming logic problem.
Btw... the queues I am talking about are server side not client side. The client side message queuing is handled by the Flash Player internals.

Could a user queue in its default configuration cause such a problem? (as you may have guessed, I have no idea how to configure the queues, or what each setting might do)


Yes. If you don't know how to configure it read our documentation ( Chapter 2.2 ) and experiment different settings. There's no golden rule, it depends a lot on your application.

One more question, what happens client side if the game is using 100% processor and smartfox messages are coming in. Do they get delayed because the flash player is at 100% cpu? Might they even get dropped?

Delayed: it's likely, Dropped: no.