Server dropping UDP packets
Re: Server dropping UDP packets
When you tested on PC, Android and iOS where you using the same network?
Re: Server dropping UDP packets
i guess this was never solved right?
Re: Server dropping UDP packets
Apparently not. It's a rather old post (8 months ago) but it looks like the poster didn't reply.
Why are you asking?
Why are you asking?
Re: Server dropping UDP packets
because it's still going on... it's been like that for years
Re: Server dropping UDP packets
What is going on exactly? This is an old post that spawns 7 pages...
I presume you're referring to this error?
If you're running a recent version of SFS2X (2.13.x) you can manually add this setting to your SFS2X/config/server.xml
at the bottom of the file, before the closing main tag.
This is basically telling the server to ignore client UDP port changes at the cost of reducing security (but there's no alternative).
At the moment this is still an "experimental" feature, but I think it will be official since the next update.
Other customers have tried it and reported that the issue was gone.
Let us know.
I presume you're referring to this error?
If that's the case we've discussed it quite a lot and it's got to do with external routers or poor mobile support, not SFS2X per se (in fact it happens with any server).Discard UDP packet from ..., reason: Sender UDP Port doesn't match current session port: X != Y
If you're running a recent version of SFS2X (2.13.x) you can manually add this setting to your SFS2X/config/server.xml
Code: Select all
<allowClientUdpPortChanges>false</allowClientUdpPortChanges>This is basically telling the server to ignore client UDP port changes at the cost of reducing security (but there's no alternative).
At the moment this is still an "experimental" feature, but I think it will be official since the next update.
Other customers have tried it and reported that the issue was gone.
Let us know.
Re: Server dropping UDP packets
Your fix is not working! We still receive error "UDP port change'Lapo wrote:What is going on exactly? This is an old post that spawns 7 pages...
If you're running a recent version of SFS2X (2.13.x) you can manually add this setting to your SFS2X/config/server.xmlat the bottom of the file, before the closing main tag.Code: Select all
<allowClientUdpPortChanges>false</allowClientUdpPortChanges>
This is basically telling the server to ignore client UDP port changes at the cost of reducing security (but there's no alternative).
At the moment this is still an "experimental" feature, but I think it will be official since the next update.
Other customers have tried it and reported that the issue was gone.
Let us know.
We have turned off Windows firewall on the dedicated server machine.
We face this issue in our brawler game.
To reproduce: we login to the game (at login phase we initialize UDP), then wait ~10 minutes and click "Go to battle" (after this, on server side creating game room) - when battle starts player can't move, because for movement we use UDP.
Re: Server dropping UDP packets
What version of SFS2X are you running?
The allowClientUdpPortChanges flag was added in SFS2X 2.13.1
Also, does the problem appear mobile? PC? Both?
What client type?
Thanks
The allowClientUdpPortChanges flag was added in SFS2X 2.13.1
Also, does the problem appear mobile? PC? Both?
What client type?
Thanks
Re: Server dropping UDP packets
2.13.2Lapo wrote:What version of SFS2X are you running?
The allowClientUdpPortChanges flag was added in SFS2X 2.13.1
Mobile (Android)Lapo wrote:Also, does the problem appear mobile? PC? Both?
Unity 2018.1.1Lapo wrote:What client type?
Thanks for quick response
Re: Server dropping UDP packets
Sorry, there is misunderstanding with the flag allowClientUdpPortChanges.Lapo wrote:What version of SFS2X are you running?
The allowClientUdpPortChanges flag was added in SFS2X 2.13.1
Also, does the problem appear mobile? PC? Both?
What client type?
Thanks
How it should be to fix the error?
True or false?
Re: Server dropping UDP packets
Hi,
The parameter must be added manually to the config server.xml file, under the <serverSettings> node.
Like this:
Once you have applied the change to config file you need to restart the server. If you keep seeing those UDP errors then please send us the zipped logs so we can take a look. You can send them to our support@... email box with a reference to this discussion.
Thanks
What misunderstanding?Zed wrote:
Sorry, there is misunderstanding with the flag allowClientUdpPortChanges.
How it should be to fix the error?
The parameter must be added manually to the config server.xml file, under the <serverSettings> node.
Like this:
Code: Select all
<serverSettings>
...
...
<allowClientUdpPortChanges>false</allowClientUdpPortChanges>
</serverSettings>
What are you referring to?True or false?
Once you have applied the change to config file you need to restart the server. If you keep seeing those UDP errors then please send us the zipped logs so we can take a look. You can send them to our support@... email box with a reference to this discussion.
Thanks
-
qazokmijn01
- Posts: 21
- Joined: 15 May 2018, 08:34
Re: Server dropping UDP packets
I try add config <allowClientUdpPortChanges>false</allowClientUdpPortChanges>
But it not working . I used version smartfox 2.14
But it not working . I used version smartfox 2.14
Code: Select all
18 Feb 2020 | 06:46:46,975 | WARN | SFSWorker:Sys:4 | v2.protocol.SFSIoHandler | | Discard UDP packet from 125.214.51.209:54133, reason: Sender UDP Port doesn't match current session port: 54133 != 9225
18 Feb 2020 | 06:46:47,012 | WARN | SFSWorker:Sys:2 | v2.protocol.SFSIoHandler | | Discard UDP packet from 125.214.51.209:54133, reason: Sender UDP Port doesn't match current session port: 54133 != 9225
18 Feb 2020 | 06:46:47,027 | WARN | SFSWorker:Sys:3 | v2.protocol.SFSIoHandler | | Discard UDP packet from 125.214.51.209:54133, reason: Sender UDP Port doesn't match current session port: 54133 != 9225
18 Feb 2020 | 06:46:47,043 | WARN | SFSWorker:Sys:4 | v2.protocol.SFSIoHandler | | Discard UDP packet from 125.214.51.209:54133, reason: Sender UDP Port doesn't match current session port: 54133 != 9225 Re: Server dropping UDP packets
Hi,
you need the allowClientUdpPortChanges setting to be set to true:
Then restart the server.
Thanks
you need the allowClientUdpPortChanges setting to be set to true:
Code: Select all
<allowClientUdpPortChanges>true</allowClientUdpPortChanges>Thanks
-
qazokmijn01
- Posts: 21
- Joined: 15 May 2018, 08:34
Re: Server dropping UDP packets
I will try if it works well or not I will answer.Lapo wrote:Hi,
you need the allowClientUdpPortChanges setting to be set to true:Then restart the server.Code: Select all
<allowClientUdpPortChanges>true</allowClientUdpPortChanges>
Thanks
Sorry my english not good
Re: Server dropping UDP packets
We are experiencing 100% UDP packet missing issue. SFS2.15.
This does not happen all the time, but from time to time, the session's UDP packets will not be received by client. No errors observed on either side. Don't know how to reproduce or under what condition this issue happens. TCP packets works with no drops but UDP are all missing.
Any ideas what could be causing this?
This does not happen all the time, but from time to time, the session's UDP packets will not be received by client. No errors observed on either side. Don't know how to reproduce or under what condition this issue happens. TCP packets works with no drops but UDP are all missing.
Any ideas what could be causing this?
Re: Server dropping UDP packets
Can you give us more details?
100% packets missing after the initial initUDP call?
Or after a certain amount of activity?
Are there long pauses during which the client is not sending or receiving any UDP packets? If that's the case it could be a matter of adding a small keep alive call between client and server to avoid the client silently recycle the ephemeral port (if no transmission is seen for a while).
Let us know
100% packets missing after the initial initUDP call?
Or after a certain amount of activity?
Are there long pauses during which the client is not sending or receiving any UDP packets? If that's the case it could be a matter of adding a small keep alive call between client and server to avoid the client silently recycle the ephemeral port (if no transmission is seen for a while).
Let us know