Server dropping UDP packets
Re: Server dropping UDP packets
Sorry, I am not sure to follow. What check are you referring to?
- janheuninck
- Posts: 68
- Joined: 23 Nov 2011, 01:35
- Location: Vancouver BC, Canada
Re: Server dropping UDP packets
Lapo wrote:Sorry, I am not sure to follow. What check are you referring to?
Well, the SFSIoHandler detects the change of session port, cause it shows this error message:
Code: Select all
protocol.SFSIoHandler - Discard UDP packet from 97.75.172.122:34321, reason: Sender UDP Port doesn't match current session port: 34321 != 28290
Instead of discarding this packet, is it possible to process the packet anyway?
Code: Select all
if (isSessionPortChangingAllowed())
{
// Process the packet
}
else
{
// Discard the UDP packet
}
Or am I seeing it too simplistic?
Re: Server dropping UDP packets
For security reasons it's not possible. Allowing the client to reset the port in the middle of the communication would allow another client to act as someone else.
- janheuninck
- Posts: 68
- Joined: 23 Nov 2011, 01:35
- Location: Vancouver BC, Canada
Re: Server dropping UDP packets
Lapo wrote:For security reasons it's not possible. Allowing the client to reset the port in the middle of the communication would allow another client to act as someone else.
I understand, but can you give us at least the option to disable it? It's causing a lot of problems for us...
Re: Server dropping UDP packets
We'll look into that, but I would like to understand more.
What client are you using (iOS, Java etc...) and what kind of test are you running. I have done quite a lot of testing and never seen this phenomenon.
I guess one possible way to recreate it is to run a very long session (many hours) with few long pauses in between, maybe under these conditions the UDP port on the client gets reassigned.
As far as I know most high level API (Flash, Unity, Java...) allow for a UDP connection even if the protocol is in actuality connection-less. This means that once the connection is initiated the port in use will not be changed.
I'd like to understand more about what's happening
What client are you using (iOS, Java etc...) and what kind of test are you running. I have done quite a lot of testing and never seen this phenomenon.
I guess one possible way to recreate it is to run a very long session (many hours) with few long pauses in between, maybe under these conditions the UDP port on the client gets reassigned.
As far as I know most high level API (Flash, Unity, Java...) allow for a UDP connection even if the protocol is in actuality connection-less. This means that once the connection is initiated the port in use will not be changed.
I'd like to understand more about what's happening
- janheuninck
- Posts: 68
- Joined: 23 Nov 2011, 01:35
- Location: Vancouver BC, Canada
Re: Server dropping UDP packets
Lapo wrote:What client are you using (iOS, Java etc...) and what kind of test are you running. I have done quite a lot of testing and never seen this phenomenon.
We are running our game on iOS devices (iPads, all loaded with firmware 6.1+, in combination with the latest iOS SFS API). We can't really explain when it happens, cause it seems very random. Sometimes (maybe 1 percent of the time) we get the error when we test on the wireless network at the office. Some people get the issue more often when they connect from their home network. We can't reproduce the problem, but when it occurs it's very frustrating.
I wish we had more details for you, but we haven't. Thanks for considering making the security check optional!
- janheuninck
- Posts: 68
- Joined: 23 Nov 2011, 01:35
- Location: Vancouver BC, Canada
Re: Server dropping UDP packets
Hi Lapo,
Any news if you guys are going to implement this feature?
Tnx
Jan
Any news if you guys are going to implement this feature?
Tnx
Jan
Re: Server dropping UDP packets
Hi, no news at the moment, sorry.
It's in our to-do list for the next release. I'll keep you posted.
It's in our to-do list for the next release. I'll keep you posted.
Re: Server dropping UDP packets
Hi Lapo,
Any update on this. when is the next release expected. we are also facing same issue
Thanks,
Shanta
Any update on this. when is the next release expected. we are also facing same issue
Thanks,
Shanta
Re: Server dropping UDP packets
It would help to know how to reproduce the problem. So far we haven't been able to create the same issue locally.
Very often this is caused by external devices, such as firewalls.
Very often this is caused by external devices, such as firewalls.
Re: Server dropping UDP packets
Hi Lapo,
Yes even in our local environment it works fine, this issues occurs when it is goes through firewall. Due to some reason it changes the UDP port and from then the server starts discarding packets and client cannot receive any UDP packets
After re launching game everything works fine for some time.
We are running our game on unity.
Yes even in our local environment it works fine, this issues occurs when it is goes through firewall. Due to some reason it changes the UDP port and from then the server starts discarding packets and client cannot receive any UDP packets
After re launching game everything works fine for some time.
We are running our game on unity.
Re: Server dropping UDP packets
You might want to check the firewall configuration with your hosting provider, explaining the UDP packet issue you are having.
Re: Server dropping UDP packets
Hello Lapo,
We are running into this problem intermittently, and checking our firewall, but assuming that for some reason the cause for this port change lies outside of our direct control. Will there be an option to disable the check in the near future?
Thanks,
Ritch...
We are running into this problem intermittently, and checking our firewall, but assuming that for some reason the cause for this port change lies outside of our direct control. Will there be an option to disable the check in the near future?
Thanks,
Ritch...
Re: Server dropping UDP packets
Hi,
we had a client who was going though the same problem. Their Unity client was working correctly for a while and then the client UDP port was suddenly changed leading to server side errors.
We investigated and concluded that this wasn't an SFS API issue or server problem. They couldn't reproduce it locally, and similarly we failed at recreating the problem.
After some further investigation it turned out that their server-side router was causing the issue by deliberately changing UDP port numbers after some time. With a little bit of configuration the issue was removed.
I would highly recommend to those having a similar problem to ask your hosting/server admin to take a look at the router/firewall configuration explaining the problem of UDP port change. This is absolutely the best way to resolve the issue.
we had a client who was going though the same problem. Their Unity client was working correctly for a while and then the client UDP port was suddenly changed leading to server side errors.
We investigated and concluded that this wasn't an SFS API issue or server problem. They couldn't reproduce it locally, and similarly we failed at recreating the problem.
After some further investigation it turned out that their server-side router was causing the issue by deliberately changing UDP port numbers after some time. With a little bit of configuration the issue was removed.
I would highly recommend to those having a similar problem to ask your hosting/server admin to take a look at the router/firewall configuration explaining the problem of UDP port change. This is absolutely the best way to resolve the issue.
Re: Server dropping UDP packets
Hello,
We are still running into this issue intermittently. It is happening on both our production and development networks (to varying degrees). The firewall settings in both environments have the UDP timeout set to 2 mins and our client is sending UDP packets at a minimum of 2 times a second currently (so there should be no timeouts due to inactivity that we know of) and we have not tied it to any specific time length of a connection. Is this most certainly a local firewall/NAT issue or could it be an issue with the remote environment. Maybe some aberrant behaviour from a 3G environment similar to this link
http://stackoverflow.com/questions/4106 ... connection
or a non-compliant network exhibiting non-deterministic behaviour as described in this doc from IETF
http://tools.ietf.org/html/rfc4787#section-4.1
or any other odd filtering on the remote network. What would be your suggestion on a specific plan of action, if not the ability to accept the messages? When encountered is there a method to follow for connection recovery to allow UDP traffic to work again for the client (currently the client connection will no longer be able to use UDP messaging until they disconnect, and then reconnect)? Is the state detectable?
We are still running into this issue intermittently. It is happening on both our production and development networks (to varying degrees). The firewall settings in both environments have the UDP timeout set to 2 mins and our client is sending UDP packets at a minimum of 2 times a second currently (so there should be no timeouts due to inactivity that we know of) and we have not tied it to any specific time length of a connection. Is this most certainly a local firewall/NAT issue or could it be an issue with the remote environment. Maybe some aberrant behaviour from a 3G environment similar to this link
http://stackoverflow.com/questions/4106 ... connection
or a non-compliant network exhibiting non-deterministic behaviour as described in this doc from IETF
http://tools.ietf.org/html/rfc4787#section-4.1
or any other odd filtering on the remote network. What would be your suggestion on a specific plan of action, if not the ability to accept the messages? When encountered is there a method to follow for connection recovery to allow UDP traffic to work again for the client (currently the client connection will no longer be able to use UDP messaging until they disconnect, and then reconnect)? Is the state detectable?
Who is online
Users browsing this forum: Google [Bot] and 103 guests