Would it be possible for you to replicate the issue, but with wireshark monitoring the traffic to port 8999? That could help confirming on denying the theory about it being torrents. Latter scenario seems likely given how it only occurs after server runs for some - what was the ballpark number of dropped clients in the stdout? Even just order of magnitude should be useful information. 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.). That would basically make this a performance issue. Dropping clients like described in the log you pasted would imply that it at least tried to deal with it correctly. Syncplay indeed should be resistant to receiving moderate amounts of garbage data.IMHO this alone makes observed behavior fairly unlikely.
#Utorrent syncplay torrent
I think it can only really happen if both torrent client and Syncplay server are only run periodically - it's not really possible for both of them to use the same port at the same time.
Though there are few things of note to consider: This would perfectly explain observed behavior. Looking at syncplay server's stdout, augmented by printing out the non-utf-8 string referenced by the error message:Īny 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.Īfter digging a bit it seems that once you connect to modern torrent network your IP/port gets passed around for a good while. This only starts happening an indeterminate amount of time after starting up the server (less than 24 hours). Connection with server lost, attempting to reconnect
0 kommentar(er)
