-
-
Notifications
You must be signed in to change notification settings - Fork 600
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Connections are not terminated after ending the session #379
Comments
It is normal that with ice lite turned off it uses twice as much ports, because it needs to establish bidirectional communication - to allocate one port for sending and one port for receiving data, to be able to work around various NATs. UDP is stateless and there is no handshake, therefore the lifecycle of UDP connection must be closed explicitly by the app when the user has been detected to be disconnected. There are as well various timeouts that handle this connection, in our case 6 seconds. See in library source code. I assume you refreshed the page quicky, and probably the connection was not yet closed. From your logs i see that the connection was closed Could you please join on the browser in neko, wait until it comes online and then close the browser. Look into logs and wait until you see Reason for this behavior is: When the user is unexpectedly disconnected, because this could happen in real use case when your computer/mobile would switch networks or you would be in a train and your cellular network would switch transmitters. However, I agree, that page reload could be probably somehow detected and the ports could be claimed quicky without waiting for the timeout. |
Thanks for your reply @m1k1o! I noticed the logs about destroying session and pipeline after waiting a couple of seconds without refreshing, however the ports still do not seem like they are freed since I am not able to reconnect again even after waiting one hour. Once the connection is gone like I stated in my first post, I never succeeded to connect neko regardless of the amount of time I waited. Is it still the expected behavior from neko or is there a possibility that ports remain busy unexpectedly after terminating UDP connection? |
No. That's definitely unexpected. Ports should be freed after timeout. I'll take a look. |
Any updates on this? |
I was able to reproduce this one. Simply setting EPR port tange to two ports and the third refresh is not working anymore. When using I also checked demodesk fork and there the issue does not exists, therefore I would address this as part of v3 rewrite #371. |
Hey there,
I recently discovered that neko possibly fails to terminate UDP connections when the user ended session. I have tested the situation with the following configuration:
When running the container using
docker-compose up
, and go to the localhost:8080, neko and XFCE window opens successfully. However, after two or three refreshes in browser, neko fails to deliver XFCE screen and gives black screen with an error message saying "Disconnected peer failed".Logs
Here are the logs between two browser refreshes:
Further Observations
I have managed to reproduce the issue in AWS and on-premise environments as well, here are my notes:
NEKO_ICELITE
istrue
,NEKO_EPR
is 52000-52007 andNEKO_NAT1TO1
is unset, neko fails after ~8-10 refreshes.NEKO_ICELITE
isfalse
,NEKO_EPR
is 52000-52007 andNEKO_NAT1TO1
is the public IP of the EC2 instance, neko fails after ~4-5 refreshes.NEKO_ICELITE
istrue
,NEKO_EPR
is 52000-52007 andNEKO_NAT1TO1
is unset, neko fails after ~8-10 refreshes.NEKO_ICELITE
isfalse
,NEKO_EPR
is 52000-52007 andNEKO_NAT1TO1
is the internal IP of the server, neko fails after ~4-5 refreshes.Additionally, in AWS and on-premise tests, neko produced multiple logs for each UDP port in failure (black screen) as below:
I guess that the refresh count before failure is close to the max allowed sessions in neko configuration. (since 8 ports correspond to 4 user sessions when NAT1TO1 is used)
Any kind of help is appreciated. Thanks!
The text was updated successfully, but these errors were encountered: