Server dropping UDP packets

Post here your questions about SFS2X. Here we discuss all server-side matters. For client API questions see the dedicated forums.

Moderators: Lapo, Bax

User avatar
Lapo
Site Admin
Posts: 22999
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Server dropping UDP packets

Postby Lapo » 12 May 2013, 18:20

Hi,
sorry for the delay in responding and thanks for the links.

As regards recovering from that situation it's quite difficult to say. The way most languages (such as Java, C#, Actionscript etc...) work with UDP is that they abstract a connection even though the protocol doesn't really use a connection. The abstraction however allows to easily handle multiple channels of communication and allow to recognize clients from their IP/port values. If this mechanism is broken by an outside device such as a NAT or similar, it can cause all sorts of problems.

I think at this moment the most problematic is UDP with mobile devices. Many 3G networks don't even support UDP and performance in general is not exciting because of the higher rate of packet loss. To avoid most of these issues it is best to stick with TCP or at least make sure the application is able to fall back to TCP in case of problems.
Lapo
--
gotoAndPlay()
...addicted to flash games
rparker
Posts: 19
Joined: 18 Oct 2010, 09:10

Re: Server dropping UDP packets

Postby rparker » 16 May 2013, 11:08

We are using a fallback method that utilizes TCP connection, but one of the main reasons we switched to 2x was to get support for the UDP protocol. And in the the cases of this that we know of it seems that the packets are identified as belonging to a known user, just with a changed port (unless there is more to this, but we have no way of knowing since the packets are dropped). To detect the state we are doing a periodic round trip UDP check and after our threshold of failures is reached we assume the packets are not getting through. If there is some built-in detection for this state please let us know. Also, mobile devices are a big part of our target users for the latest update to our MMO environment and having our UDP communications as consistent as possible is important to us, so if accepting these packets gets us that much closer then we would like to option to do so.
User avatar
Lapo
Site Admin
Posts: 22999
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Server dropping UDP packets

Postby Lapo » 16 May 2013, 12:25

Unfortunately if some external "entity" affects the connection by changing the source port we have no way to detect it. The source IP and port are two indispensable parameters to identify the sender.
Lapo

--

gotoAndPlay()

...addicted to flash games
sudhir
Posts: 4
Joined: 03 Mar 2012, 00:54

Re: Server dropping UDP packets

Postby sudhir » 18 May 2013, 09:49

Lapo,

Is there a way to turn this feature off then? The server seems to know that something is amiss for a particular sender, since it logs the source-port change in its log files. So, any way to tell the server to ignore this condition and keep going? Or, since this seems to be a fairly common occurrence, and IETF standards acknowledge it, is there any other UDP solution at all that will allow us to continue unhampered by this issue? As Rich mentions, switching to TCP is compromising the real-time nature of certain games. We're about to put out a new game under a large brand (see http://www.schoolofdragons.com) and so this issue is giving us a fair bit of heartburn right now! If we need to fall back to TCP, can you suggest any way to eliminate real-time synchronization issues for example, in a racing game? If one person switches back into TCP while everyone else is on UDP, the experience is going to be bad for ALL users in that race. Any help/suggestions are appreciated.

Thanks,
Sudhir
User avatar
Lapo
Site Admin
Posts: 22999
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Server dropping UDP packets

Postby Lapo » 20 May 2013, 07:51

I think this has been explained a couple of times in this thread.
The UDP protocol requires an initialization in order to ensure that the client CAN use the protocol. Once the initialization is done the client and server agree to use a certain port and it should never change.
The client has no way to detect a port change because this is "trick" played by a device outside of the system. The solution to this issue is making sure that no Router or Firewall, standing in front of the server, is allowed to change the source port of the client.
Lapo

--

gotoAndPlay()

...addicted to flash games
sudhir
Posts: 4
Joined: 03 Mar 2012, 00:54

Re: Server dropping UDP packets

Postby sudhir » 21 May 2013, 14:03

Lapo,

Thank you for your patience on this, and I think we do understand the issue... we're not questioning that this is indeed what's happening. The issue is that this "trick" you're describing appears to be a fairly commonplace issue, and since it's happening at the client, we have no control over the routers... especially in a mass market situation. We're not likely to have much success trying to get an average customer to configure their routers in some particular way just to use our configuration -- and even if we could, it certainly isn't a cost scalable solution to do this. It's become clear through various avenues of exploration that there is nothing we can do on the server side. And as we just explained, the statement that the source port should never change has sanctioned loopholes where apparently this change is permitted.

So the question for us as implementers is, how do we solve the user experience problems that result from this situation. If it cannot be fixed for whatever reason, can we at least have some control over how to respond when this happens... given that SFS seems to know it's happening (as evidenced by the log entries that announce port changes for a client). Or am I missing something completely here?

Thanks,
Sudhir
User avatar
Lapo
Site Admin
Posts: 22999
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Server dropping UDP packets

Postby Lapo » 21 May 2013, 16:03

Hi Sudhir,
actually I am not so sure how frequent this problem is, on the client side. Do you have figures? We have had a couple of customer where this problem was massively present but it turned out that it was their network setup (i.e. server-side) and once they configured their devices correctly the issue went away.

On the client side I don't really think the situation is so bad. We have tested UDP-based demos with dozens of different users and developers, each one was behind their routers and no one experienced issues with the UDP protocol. It's a small sample but added to the many other projects I know of it is telling me that the situation is not as bad as it seems.
For example I wouldn't expect most of the home modem/routers to cause any issues with UDP otherwise many other services would fail as well and in general the complaints that we see for this issue is minimal.

This leaves us with maybe internet access from corporate offices and UDP from mobile devices. For these scenarios switching to TCP is probably the best solution and at times might not even be sufficient. In fact many companies use tight security configurations and won't permit neither UDP nor TCP sockets. For those unlucky scenarios we provide the BlueBox/HTTP tunnelling which is still a good choice even for some action games.

On smartphones the big question is related to the ability of the 3G operators to provide UDP support. It's my understanding that there're still quite a bit of problems for this aspect, and developers can find all sorts of troubles.

So the question for us as implementers is, how do we solve the user experience problems that result from this situation. If it cannot be fixed for whatever reason, can we at least have some control over how to respond when this happens... given that SFS seems to know it's happening (as evidenced by the log entries that announce port changes for a client). Or am I missing something completely here?

Very good question. Unfortunately I don't have an equally good answer :( The server complains about unrecognized UDP packets when they don't belong to any known session. If you only had one client behind every IP address connected it might be easy to deduce the owner of the packet, but often times this is not the case.
Lapo

--

gotoAndPlay()

...addicted to flash games
sudhir
Posts: 4
Joined: 03 Mar 2012, 00:54

Re: Server dropping UDP packets

Postby sudhir » 21 May 2013, 17:01

Ok, thanks Lapo. We'll get you some figures... at times, it looks alarmingly frequent in the logs ; but to your point, we almost always test from within corporate networks. Perhaps that's causing a spike in this activity that would not manifest in the real (home network) world.

Thanks,
Sudhir
RävenAB
Posts: 14
Joined: 28 May 2013, 14:41

Re: Server dropping UDP packets

Postby RävenAB » 28 Aug 2013, 16:10

What's the latest on this issue? We've tried a couple of different server setups, and very frequently we end up with the UDP packet error (error message below). Seems the only reliable way to avoid the problem is running within the same LAN, but obviously that's not an option.

We're running SFS 2.7.0, with the latest API for Unity (1.3.0). We've tried both standalone-PC and Android, intermittently failing on both.

Code: Select all

java.lang.IllegalStateException: UDP Packet cannot be sent to: { Id: 3, Type: DEFAULT, Logged: Yes, IP: [i]{IP-ADRESS}[/i] }, no DatagramChannel was ever set!
   com.smartfoxserver.bitswarm.core.SocketWriter.udpSend(SocketWriter.java:449)
   com.smartfoxserver.bitswarm.core.SocketWriter.processRegularSession(SocketWriter.java:279)
   com.smartfoxserver.bitswarm.core.SocketWriter.processSessionQueue(SocketWriter.java:201)
   com.smartfoxserver.bitswarm.core.SocketWriter.run(SocketWriter.java:177)
   java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
   java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
   java.lang.Thread.run(Unknown Source)
User avatar
Lapo
Site Admin
Posts: 22999
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Server dropping UDP packets

Postby Lapo » 28 Aug 2013, 17:21

This problem has been discussed in possibly 2 other threads and we have followed a customer on the same issue.

UDP ports are not meant to be changed around while an application is running but it can happen if there's a firewall in between the two parties (client / server). This is the only situation in which we have seen the problem happening for some customer and it's not easy to solve from our side.
The customer we followed solved it by asking the sysadmin to configure their firewall so that client UDP ports were not changed over time.
Lapo

--

gotoAndPlay()

...addicted to flash games
RävenAB
Posts: 14
Joined: 28 May 2013, 14:41

Re: Server dropping UDP packets

Postby RävenAB » 28 Aug 2013, 17:34

Thanks for the quick response.

Lapo wrote:The customer we followed solved it by asking the sysadmin to configure their firewall so that client UDP ports were not changed over time.


I understand setting up the server and it's possible firewall is crucial (and we're actually running our dev server without any firewall at the moment), but how do we control any potential firewalls used by the clients?
User avatar
Lapo
Site Admin
Posts: 22999
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Server dropping UDP packets

Postby Lapo » 28 Aug 2013, 17:48

It is unlikely that it will happen with a personal firewall on client side.
The problem you can see with client side firewalls is that they won't be able to use UDP at all, if the configuration is very restrictive.
Lapo

--

gotoAndPlay()

...addicted to flash games
csivi
Posts: 2
Joined: 27 Aug 2014, 22:12

Re: Server dropping UDP packets

Postby csivi » 28 Aug 2014, 10:19

Hi Smartfox!

I also have this problem, but my side is most intresting, because when i expand my extension and upload in to the server then the server say that:

09:06:03,977 INFO [main] v2.SmartFoxServer - Boot sequence starts...
09:06:03,987 INFO [main] v2.SmartFoxServer -
_____ _____ _____ ___ __ __ _____ _____ _____ _____
| __| __| __| |_ | | | | __ | | |_ _|
|__ | __|__ | | _|- -| | __ -| | | | | | |
|_____|__| |_____| |___|__|__| |_____|_____|_____| |_|

09:06:05,191 INFO [main] core.SFSEventManager - AnonymousService-1 initalized
09:06:05,279 INFO [main] impl.DefaultFileReplicator - Using "/tmp/vfs_cache" as temporary files store.
09:06:05,474 INFO [main] v2.SmartFoxServer - License loaded:

===================================
LICENSE DETAILS
-----------------------------------
Type : Community Edition
Max users : 100
===================================

09:06:05,476 INFO [main] managers.SFSBannedUserStorage - BanUserStorage initialized
09:06:05,485 INFO [main] managers.SFSBannedUserManager - BanUser data loaded: 0 records.
09:06:05,489 INFO [main] v2.SmartFoxServer - Protocol Type is: BINARY
09:06:05,491 INFO [main] config.DefaultConfigLoader - Loading: zones/SporeGame.zone.xml
09:06:05,580 INFO [main] managers.SFSZoneManager -

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>> Zone: SporeGame
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

09:06:05,679 INFO [main] managers.SFSRoomManager - Room created: { Zone: --=={{{ AdminZone }}}==-- }, [ Room: AdminRoom, Id: 0, Group: default, isGame: false ]
09:06:05,686 INFO [main] core.AdminToolService - AdminTool Service started
09:06:05,877 INFO [SFSWorker:Sys:1] v2.SmartFoxServer - Listening Sockets: { 87.229.45.107:9933, (Tcp) } { 87.229.45.107:9933, (Udp) }
09:06:05,877 INFO [SFSWorker:Sys:1] v2.SmartFoxServer -
_____ _____ _____ ___ __ __
| __| __| __| |_ | | |
|__ | __|__ | | _|- -|
|_____|__| |_____| |___|__|__|
_____ _____ _____ ____ __ __
| __ | __| _ | \| | |
| -| __| | | |_ _|
|__|__|_____|__|__|____/ |_|
[ 2.9.0 ]

09:06:05,877 INFO [SFSWorker:Sys:1] v2.SmartFoxServer - SmartFoxServer 2X (2.9.0) READY!
09:06:08,968 INFO [main] v3.SessionFilter - BlueBox-2X Service (3.0.0) ready.
09:08:54,890 INFO [SocketReader] sessions.DefaultSessionManager - Session created: { Id: 1, Type: DEFAULT, Logged: No, IP: 78.92.239.49:50537 } on Server port: 9933 <---> 50537
09:08:55,018 INFO [SFSWorker:Sys:4] api.SFSApi - User login: { Zone: SporeGame }, ( User Name: joco, Id: 0, Priv: 0, Sess: 78.92.239.49:50537 ) , Type: Flash
09:08:57,517 INFO [SocketReader] sessions.DefaultSessionManager - Session created: { Id: 2, Type: DEFAULT, Logged: No, IP: 78.92.239.49:52595 } on Server port: 9933 <---> 52595
09:08:57,624 INFO [SFSWorker:Sys:1] api.SFSApi - User login: { Zone: SporeGame }, ( User Name: csivi, Id: 1, Priv: 0, Sess: 78.92.239.49:52595 ) , Type: Flash
09:09:00,285 INFO [SFSWorker:Sys:3] managers.SFSRoomManager - Room created: { Zone: SporeGame }, [ Room: AutoRoom_7411859, Id: 1, Group: normal, isGame: false ]
09:09:00,288 INFO [SFSWorker:Sys:3] api.SFSApi - Room joined: [ Room: AutoRoom_7411859, Id: 1, Group: normal, isGame: false ], { Zone: SporeGame }, ( User Name: csivi, Id: 1, Priv: 0, Sess: 78.92.239.49:52595 ) , asSpect: false
09:09:03,918 INFO [SFSWorker:Sys:1] api.SFSApi - Room joined: [ Room: AutoRoom_7411859, Id: 1, Group: normal, isGame: false ], { Zone: SporeGame }, ( User Name: joco, Id: 0, Priv: 0, Sess: 78.92.239.49:50537 ) , asSpect: false
09:09:30,848 WARN [SFSWorker:Sys:3] protocol.SFSIoHandler - Discard UDP packet from 78.92.239.49:1024, reason: Sender UDP Port doesn't match current session port: 1024 != 62480
09:09:30,921 WARN [SFSWorker:Sys:4] protocol.SFSIoHandler - Discard UDP packet from 78.92.239.49:1024, reason: Sender UDP Port doesn't match current session port: 1024 != 62480
09:09:30,962 WARN [SFSWorker:Sys:2] protocol.SFSIoHandler - Discard UDP packet from 78.92.239.49:1024, reason: Sender UDP Port doesn't match current session port: 1024 != 62480
09:09:31,004 WARN [SFSWorker:Sys:4] protocol.SFSIoHandler - Discard UDP packet from 78.92.239.49:1024, reason: Sender UDP Port doesn't match current session port: 1024 != 62480
09:09:31,039 WARN [SFSWorker:Sys:2] protocol.SFSIoHandler - Discard UDP packet from 78.92.239.49:1024, reason: Sender UDP Port doesn't match current session port: 1024 != 62480
09:09:31,077 WARN [SFSWorker:Sys:4] protocol.SFSIoHandler - Discard UDP packet from 78.92.239.49:1024, reason: Sender UDP Port doesn't match current session port: 1024 != 62480



And the end when i put back the old extension the WARNING is disappears and everything is works!!

So i tryed this options:

1. I did a same extension which was the old, then uploded the JAR-file to the server and the WARNING is come back... it's not good!

2. I updated the SmartFoxServer 2.7 to 2.9 and the 1.2 ActionScript 3 API to... WARNING is come back and it's not good!

3. I reinstall my Flash builder 4.7... WARNING is come back and it's not good!

4. I reinstall my Eclipse, create new project etc... WARNING is come back and it's not good!

So please SmartFox help me, i can't proceed my project!

Thanks in advance for your help!
User avatar
Lapo
Site Admin
Posts: 22999
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Server dropping UDP packets

Postby Lapo » 28 Aug 2014, 11:48

You haven't explained what's the difference between the old and the new Extension.
The problem with the UDP packets refused, as explained earlier, depends on factors that are external to the server, like a firewall that arbitrarily decides to switch UDP ports at runtime.

If you're never getting any errors with the "old Extension", chances are you're not using UDP at all, supposing that all other variables are unchanged (network, firewall, client etc...)
Lapo

--

gotoAndPlay()

...addicted to flash games
csivi
Posts: 2
Joined: 27 Aug 2014, 22:12

Re: Server dropping UDP packets

Postby csivi » 28 Aug 2014, 12:15

I used UDP in old extension to! I wrote the same as that of the previous extension and I exported in .jar file and uploaded to server but the WARNING is comes again. But when i put it back the old extension what i wrote in 2012. december then the WARNING is disappears and everything is works!! In server any ports are opened, no fire wall etc..

Return to “SFS2X Questions”

Who is online

Users browsing this forum: No registered users and 42 guests