Client randomly doesn't get a sole seed from the tracker #613
Comments
|
Hrm... That specific exception is suspect. It implies the underlying data is incomplete, i.e. a partial Http response was received. Could you add a line of logging around this area of the code, probably prior to the if/else, to print out the content length of the response: Also, if you dump the Memory stream to disk using System.Text.Encoding.ASCII to encode the bytes, it should be possible to eyeball the result and see what the content is. It might make it clearer whether the response is incomplete, or completely invalid. |
|
There is a lot of these being thrown: Tracker has this as a sole listener, so I guess it's trying to only use IPv6? var trackerEndpointHttp = $"*:{trackerPortHttp}";
var listenerHttp = TrackerListenerFactory.CreateHttp($"http://{trackerEndpointHttp}/announce/");Edit: When the BEncodedValue.Decode fails the reply seems to be empty, writing the response to file results in 0 bytes. Not sure how to debug it from there. The response status code is "OK". |
There's some cleanup which could be done here to reduce the frequency at which exceptions are thrown here, but it shouldn't make a difference to the actual behaviour or success of the library. The ipv6 tracker extensions state that the client should make both an ipv4 and ipv6 connection when announcing/scraping. If the tracker you're hosting only listens on ipv4, then the ipv6 announce from the client will fail. At this point the overall announce to the tracker will be considered a success as at least 1 announce variant succeeded. This way you can get ipv4 peers, ipv6 peers, or both ipv4+ipv6 peers.
That's surprising! I'll review the TrackerServer code and try to see how this could happen. Actualy i just noticed the wireshark cap so i'll check that out first! Thanks! |
|
@ManlyMarco Is this capture from a time when the response appeared empty on the client side? If so, the bug has to be on the client side as the capture does show the response has the expected data, and contentlength. Huh.
I'll assume this capture is from a time when the bug occurred and double check how HttpClient is reading the data. Edit: Which .net framework version are you running under? I recently added a dependency on a 3rd party nuget as it was the only viable way of implementing the IPv6 tracker extensions, and I'm a little worried that the bug you're seeing is in that nuget. If you're using .NET 4.7.2/4.8.x, could you try under .NET 6.0 and see if the behaviour is the same? If you're already using .NET 6.0 then it's definitely not that nuget. |
When hosting a tracker, an unexpected exception looks like it could cause an empty response to be sent to the client who announced/scraped, while also setting a '200' success code. Let's be really explicit here and log any unexpected errors while also return an internal server error (status code 500) if something unexpected really does occur. Might help diagnose #613
|
I wonder if this will shed some light on the problem: #620 If you don't have logging enabled/redirected, you can redirect logging to a file by replacing I have moderate hope this will identify the issue you're hitting :) |
|
I'm using .NET Framework 4.7.2. Running the code in .NET 6.0 does seem to make a difference but it still throws an exception in the same spot, this time I'm trying to reproduce the issue with the more detailed logging enabled, but of course it doesn't happen when I'm trying to get it to happen. It seems to have fixed itself somehow, at least for now. I'll have to test it in the same environment as before tomorrorow. I'll keep the logging enabled and if the issue reappears I'll let you know. For now I sidestepped the issue of unreliable tracker connection by manually adding the seed (I know it's IP since it's the same as the tracker given in the torrent file and the port never changes) and enabling peer exchange - this seems to always work. |
|
Here's what I've got, it seems to randomly crash parsing the incoming tracker requests, but not all of them. Client log (x is server IP): Server log (y is client IP): |
|
Ah interesting! It looks like perhaps a default port is propagating to the tracker, instead of being replaced with the actual listen port the client is using. There are two fixes:
The implementation of that is: monotorrent/src/MonoTorrent.Client/MonoTorrent.Client/ClientEngine.cs Lines 1016 to 1025 in 0c919b2 and from that I assume either the announce is happening before the IPv4 listener has bound to a local port... or something else funky is going on. I wonder if there should be another fallback, which is to just return the port you configured the listener with. If it was configured with a specific port (i.e. 12345) that value can be sent to the tracker even if the listener has not yet successfully bound to that port (potentially because some other app is currently using the port). |
When hosting a tracker, an unexpected exception looks like it could cause an empty response to be sent to the client who announced/scraped, while also setting a '200' success code. Let's be really explicit here and log any unexpected errors while also return an internal server error (status code 500) if something unexpected really does occur. Might help diagnose #613
|
This should be fixed in master now! |
|
Confirming the issue is fixed. |
Tracker and sole seeder are hosted on the server, both using monotorrent.
The client receives a torrent file that uses this tracker and tries to start downloading it.
Seemingly randomly the tracker will report 0 peers. The seed seems to always get at least 1 peer from the tracker (itself). Using an external application to download the torrent instead of monotorrent seems to always receive the peer properly.
The download is forever stuck at 0 since there are no peers. Even waiting for a very long time doesn't seem to do anything.
These are the only events being fired after starting the torrent when it fails (hash is pre-checked).
This is what happens when it works properly:
Looks like there's a bunch of http/tracker exceptions being thrown when querying the tracker, but they seem to happen even if it succeedes.
Tested on latest master build on both client and server, but I believe it kept happening on latest beta build on nuget as well as the stable build.
This is pretty critical since I'm using private torrents so no DHT which would probably be able to sidestep the issue.
Edit: When there are multiple torrents running at the same time (all using that same tracker), it seems like some of them can succeed and some can fail to get the seed from the tracker.
The text was updated successfully, but these errors were encountered: