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
Connection with server lost loop due to bittorrent traffic reaching Syncplay port #256
Comments
Hi, thanks for using Syncplay. From your gist, line 6 I'd advise you to check what is running on that port on your systems and to switch to another port number. If you are running your own server, you can pick basically any free port. |
It turns out that the port number was indeed the problem. Since 8999 is the default port and a lot of torrent clients use that port, they seem to somehow be interfering with Syncplay. I feel like this issue should be kept active though, since Syncplay should be made to be more resistant to other apps sending extraneous data to it, otherwise DoS can happen pretty easily, whether intentional or not. |
I think the relevant line of code is https://github.com/Syncplay/syncplay/blame/master/syncplay/protocols.py#L44 Does anyone want to comment on if they think this line should be removed? And, if it is removed, should it give a notification to the server that it detected this error? |
After digging a bit it seems that once you connect to modern torrent network your IP/port gets passed around for a good while. This would perfectly explain observed behavior. Though there are few things of note to consider:
That said I think it's either a very large volume of garbage data (it normally can handle over 100 concurrently connected clients even on very low end hardware and with no restarts for weeks), or the server is doing something very wrong when dropping clients like this (like leaking crazy amounts of memory, spawning threads without ever closing them etc.). Latter scenario seems likely given how it only occurs after server runs for some time. @zehric - what was the ballpark number of dropped clients in the stdout? Even just order of magnitude should be useful information. |
Some additional info that might be useful is that sometimes waiting long enough does result in clients being able to connect. I'd say ballpark around 50, sometimes less and sometimes more, connection retries would happen before the client successfully connected. Though it hasn't happened since I changed the port so I'm going off of memory here. After a day of running, I'd say I probably saw less than 50 dropped clients in the stdout.
This issue isn't a huge priority of mine to solve since it was resolved by just changing the port number, so I'm not too keen on trying to replicate the issue for now. If it comes up again I'll look into it. |
I've added a link to this issue from https://syncplay.pl/guide/trouble/ so that others can see how to resolve this issue if it occurs for them. Given that this does not seem to be a commonly occurring problem I will be closing this issue. Thanks for your assistance in helping us better understand this issue and how to resolve it. |
I don't wanna open this issue, but how would I enable the "debug mode" that @zehric posted above in a gist? Appreciate the help. |
I'm running syncplay server on linux with TLS enabled running on master branch. At some point, Windows clients running 1.6.4a and other lower versions started getting into this disconnect loop that looks like this:
This only starts happening an indeterminate amount of time after starting up the server (less than 24 hours).
Looking at syncplay server's stdout, augmented by printing out the non-utf-8 string referenced by the error message:
https://gist.github.com/zehric/fba67e7deb8eb2da27e9f45a70024a11
Any idea what's going on here? This is difficult to debug because the issue only starts happening some long period of time after starting up the server, and I'm not even sure if the client drop error has anything to do with the connection loop.
The text was updated successfully, but these errors were encountered: