SocketWriter error

[vmnikulin]

Hello!
We are use latest SFS version - 2.3.0.
For some clients I find this trace in log files ( there are THOUSANDS such messages). Why DatagramChannel wasn't set?

Code: Select all

 WARN  | SocketWriter-1 | bitswarm.core.SocketWriter |     | Error during write. Session: { Id: 241, Type: DEFAULT, Logged: Yes, IP: 91.215.233.189:15490 }
 WARN  | SocketWriter-1 | bitswarm.core.SocketWriter |     |
java.lang.IllegalStateException: UDP Packet cannot be sent to: { Id: 241, Type: DEFAULT, Logged: Yes, IP: 91.215.233.189:15490 }, no DatagramChannel was ever set!
   com.smartfoxserver.bitswarm.core.SocketWriter.udpSend(SocketWriter.java:447)
   com.smartfoxserver.bitswarm.core.SocketWriter.processRegularSession(SocketWriter.java:278)
   com.smartfoxserver.bitswarm.core.SocketWriter.processSessionQueue(SocketWriter.java:200)
   com.smartfoxserver.bitswarm.core.SocketWriter.run(SocketWriter.java:176)
   java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
   java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
   java.lang.Thread.run(Unknown Source)

I've already read topic viewtopic.php?f=18&t=13763 but it doesn't contains the answer

[Lapo]

Before any client is able to communicate via UDP he/she must perform the UDP handshake from client side. This is done by calling the initUDP() method of the client API and handling the relative response. If you fire UDP messages from an extension before that, you will get those errors.
I'd recommend to check this aspect, first.

[vmnikulin]

Of course we are already check it. And for most users it works.
But for some users (As I wrote above) such messages occurs in large number.

[Lapo]

If the issue happens only for certain users there might be a problem on their side, typically a firewall. The firewall may change the UDP port of the client which causes SFS2X to not recognize him/her anymore.

I recall the case of a client who had this issue on their side, a firewall in front of the server was juggling UDP port numbers creating the above issue for all clients. The problem was solved by re-configuring the firewall.

If you do have a firewall on your end you can duble check this aspect.

[vmnikulin]

We don't have firewall on our side.
And we can't re-configuring firewalls on client side.

If I understand correctly, we cannot use udp in this widely spread situation. And we should use tcp.

[Lapo]

It depends. You should quantify the amount of clients that have problems with UDP first before taking radical decisions.
Also it would be good to get a report from clients and understand what else might be going wrong.
If the UDP handshake fails on the client side what does your game do?