gugldollar.blogg.se

1. #Soulseek port open soulseekqt port closed code#
2. #Soulseek port open soulseekqt port closed download#

If you find any inconsistencies, errors or omissions in the documentation, please report them. To preserve the health of the Soulseek network, please do not modify or extend the protocol in ways that negatively impact the network. Since the official Soulseek client and server is proprietary software, this documentation has been compiled thanks to years of reverse engineering efforts. Let me know if you want me to move all this info over to your repo.Nicotine+ Soulseek Protocol Documentation If this bug is rooted in indirect connections being favored somehow it would make sense that the problem is much worse with Soulseek.NET. Soulseek NS didn't have any problems, and I wouldn't expect it to since it tries one type at a time.Īnother point to note is that Soulseek.NET will cancel any pending indirect connection if the direct connection is established first, whereas I believe Soulseek Qt happily connects both if both succeed. It's important to note that in order to break this reliably I have to wait for any/all established connections to disconnect first, so I think the root cause is a change in behavior in the logic that negotiates direct/indirect connections. Right now UploadFailed is handled but the diagnostic is at the debug level.Ġ6:50:58 Attempting direct connection of type P to user ('', 50025)Ġ6:50:58 Received incoming direct connection of type P from user Ġ6:50:58 Ġ7:49:59 Transfer ratm\Industry\03 - Fistful Of Steel.mp3 with request 117 for user timed outĠ7:50:42 Removed connection of type P to user ('192.168.1.1', 50556)

#Soulseek port open soulseekqt port closed code#

This has a fairly high likelihood of malfunctioning and I absolutely don't want to produce false positives and fail transfers that were not denied, so this fuzzy match is probably going to be limited to removal of the root of the path, normalizing path separators, and doing a case insensitive match.įor anything else that might fall through the gaps I'm going to have to add UploadDenied and UploadFailed events, so that calling code can at least report it to the end user. I think the plan will then be to, before attempting this 'second chance' connection, check to see whether this user has sent an UploadDenied message that matches the filename (using some fuzzy logic), and if so, use that to fail the transfer definitively before attempting the outbound connection. The odd behavior I'm seeing after UploadDenied is received is explained by the 'second chance' connection attempt added in #383 if the connection fails an outbound attempt is made, and it succeeds, but the transfer fails because the other end is not expecting it (or perhaps fails to read the file a second time).įailure to await a connection in AwaitTransferConnectionAsync is the only clue that I have that an UploadDenied message has been sent. The rest of the messages, including the very similar UploadFailed, all use the masked filename.

The first step is to get these transfers to explicitly fail when UploadDenied is sent, then see if this odd behavior still exists. I suspect that what is happening is that the remote client is sending a transfer response that indicates we are good to go, but then immediately fails because it can't open the file, sends UploadDenied, and then somehow doesn't clean up the transfer connection, or potentially doesn't cancel the connection or prevent Soulseek.NET from proceeding to establish it.

#Soulseek port open soulseekqt port closed download#

I've been able to reproduce the problem by removing a file from a share configured in Soulseek Qt and trying to download it. Troubleshooting failed downloads from a user this morning, I stumbled upon some odd behavior that is definitely a bug, but that I also don't understand.