forums.smartfoxserver.com

I'm wondering about dropped packets and what they might lead to. During games, a dropped outgoing message might throw the client out of sync with no way to recover.

There was a setting in SFS 1.6.x where a single dropped packet will immediately disconnect the client. I don't see this setting in SFS2x, so what is the correct way to approach this problem?

There's two way to operate on this:

1) Queue Size.
Open the config/core.xml file and change the <sessionPacketQueueSize> setting to allow a larger (or smaller) message queue. This is just a way to procrastinate the message dropping but it's also a great way to configure the tolerance of the Server to slow users.

For example it makes no sense for an action game to allow a User queue of 500 messages. This would simply mean that the client is way too slow and it's not able to keep up with the pace of the game.
When this happens the player's lag is quite heavy (let's say 5-600ms) so the player will anyway experience a slow and inconsistent action and if you are measuring such lag on the client side you could give him visual warnings.

2) Custom queue policy handler.
This is an advanced feature, that is not documented/available yet, and that can be used in very special cases.
You could provide a custom PacketQueuePolicy which is responsible for handling the queue and decide what to drop and when.

The interface for this class is straightforward: You are given a packet and the queue and decide what to do based on any custom rules of yours.

NOTE: this is not yet available in the Server. It will be in the final release together with the packet priority, which is another cool feature to use in order to prioritize which packets are lost first.
At the moment this is used by the system to allow dropping the UserCount updates under heavy traffic

Hope it helps

Thanks Lapo. It's a card game, therefore any dropped Extension or RoomVar message is game breaking

I've set it to 1200 now from 120. Most players have high latencies due to the game's popularity in far countries.

The queue policy handler seems very cool if I can guarantee that certain packets must reach the user. Otherwise, I'll have to implement something to resync every now and then.

Hi Lapo:
it’s been long time we are facing dropped outgoing packet issue. in the admin tool dropped outgoing packet counter is increasing gradually. in our game we are sending too many public messages. to narrow down the issue did a small load test on this.

when I send public message using built in command smartfox.Send(new PublicMessageRequest(message)); then we see dropped outgoing packet counter is increasing. if I handle public message to send through extension response then 0% dropped packet.

Any idea how it could be different from calling send publicmessageRequest than handling through extension message.

Thank you

What size is the Room where the public message is sent? It must be huge, otherwise the explanation is to be found somewhere else.

Hi Lapo,

I did little more investigation on this. actually packets are dropping even if I use extension message.
We built a logic on the server side, scheduler task interval set to 500ms so we collect all incoming packets in a hashMAP and broadcast to all clients at every 500ms.
The client will be sending 9 packets per sec.
So I ran the test for 50 users. For few min. (30min) everything was behaving as expected. Later on packets started dropping.

Each packet size is 168bytes.
size of each room is 8.

How do we control dropping packets.

Thank you

Packet dropping doesn't depend on the client rate. It depends on the server's rate and the capacity of clients to keep up with that message rate.
I think it is good to aggregate the data in larger time intervals as you have done, but you are still sending the same amount of packets only at a different rate, and if the client is not able to keep up, due to its connection, it will eventually force the server to drop packets.

The packet dropping is just a safety mechanism to avoid that thousands of undelivered packets will crash the server memory. It also serves as an indicator for client's problem.
The first thing to do is checking the packet dropping percentage. If that's below 10% it is not a real problem because it is quite expected that a small portion of clients will use slower connections. This is especially true for real-time games.

For more details please read here:
http://docs2x.smartfoxserver.com/Gettin ... g#section4

Hi Lapo,

Sorry to revive such an old thread. But I was curious if IPacketQueuePolicy is available yet. I'm still not finding the documentation for it and would like to learn more.

Cheers

Hi,
yes this is a very old thread indeed
This feature has always been low priority and we eventually realized that it wouldn't provide significant improvements. Essentially the server is already very tolerant of slow clients, pushing it any further would not improve the experience for a player after we've already discarded the non critical packet and queued up 150 messages. The game experience would remain extremely laggy.
Either the client is just too slow or, if the problem is more frequent/prevalent the game was designed to push too many packets and needs some re-thinking and optimization.

This is for TCP-based games. For UDP there's no such mechanism so the game must be designed with packet loss in mind.
Hope it helps

Hi Lapo

Sorry for necroing such an old thread.

We run two games, one very old one using SFS 1.6 and another newer one using 2x. We recently set <MaxAllowedDroppedPackets>1</MaxAllowedDroppedPackets> in the older title and it seems to have had a big positive impact on the game's multiplayer experience. We were hoping the same setting would exist in 2x but we haven't been able to find it.

From reading through this thread you suggest changing <sessionPacketQueueSize> instead, but from my understanding this won't work in the same way. Basically if a packet drops, we want the client automatically reconnect (which in our game is quick and automatic), which then pretty much fixes any desync.

Is there really no way to achieve this from the server side? It seems a shame that such a basic feature that was in 1x is missing in 2x.

Thanks
Neil

Hi,
there isn't an equivalent option in SFS2X as the original feature in SFS PRO was rarely (if ever) used. In theory making the server intolerant to packet drops would result in a worse user experience, since players with a slow/bad connection would also start disconnecting more often.

Generally speaking setting the packet queue to a super low value such as 1 seems pretty extreme, because it doesn't allow for the slightest latency on the client side. Also triggering lots of disconnections can be problematic because connecting is the slowest of all network operations (since it requires multiple packet exchanges, including login validation) and would add even more delays...

We could think about adding a mechanism for disconnecting a client when its packet queue is full, that's not an issue. But I wouldn't recommend using it with a queue size of 1. I would rather suggest to leave the queue to a reasonably small size (e.g. 20-50) and let the client recover from brief moments of laggy-ness. The disconnection would trigger anyways if a packet were to be dropped.

Otherwise you'd punishing everyone for even a minor slowness in processing the newtork.
my 2c

Thanks a bunch for your swift response. I do definitely understand your reasoning behind this, but I feel that in our specific use case it still might be helpful. As I say it has definitely improved our oldest game. I do understand it's a bit of a band-aid solution to a problem that should really be handled gracefully in other ways, but we're dealing with quite big/old games where complete rewrites of the networking code would be incredibly time consuming, costly and may lead to other issues.

I don't think we'd be looking at a queue size of 1. The setting we used for our old game was queue = 60 and maxDroppedPackets = 1 so I believe that is effectively the same as disconnection when a queue of 60 is full? Therefore we'd be looking a similar value for our 2x game.

So if you could consider implementing such a feature in the next version I would be incredibly grateful.

SmartFoxServer 2X 2.20 introduced the option to auto-disconnect clients with a maxed-out packet queue.
It can be turned on manually via the SFS2X/config/core.xml file.

https://docs2x.smartfoxserver.com/Advan ... e-settings

Cheers