-
-
Notifications
You must be signed in to change notification settings - Fork 0
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
Lots of requests to mirrobrain from Torrent client #290
Comments
@rgaudin Tested with magnet link or .torrent file? |
Both. .torrent just cannot exhibit this but magnet I can understand if the client is not following the redirection. |
Screenshot is magnet |
Not much idea, sorry ... |
I see other occurences with Transmission 4.0.6 so definitely not a 4.0.5 bug. I couldn't repro when downloading nor seeding though. Not sure how they get there |
I have some more food for thought.
This assertion seems wrong, this URL is also using as
2 more questions:
Do we have a way to test which mirror is returned by MB for this IP? |
I can confirm that I also do not achieve to reproduce the problem with transmission 4.0.6 on Mac. Even when tweaking my |
OK I found the discrepency ; I was using curl to retrieve the magnet ; and there is only MB original (but broken) version magnet:?xt=urn:btih:2db99105d8a93d2d79be696b295ae7945f336935
&xt=urn:md5:c585c41542a6af8ec25e6c819a03766e
&xl=249495052834
&dn=survivorlibrary.com_en_all_2024-09.zim
&as=http://download.kiwix.org/zim/zimit/survivorlibrary.com_en_all_2024-09.zim
&tr=http://tracker.openzim.org:6969/announce
&tr=udp://tracker.openzim.org:6969/announce libkiwix fixed version magnet:?
&xt=urn:btih:2db99105d8a93d2d79be696b295ae7945f336935
&xt=urn:md5:c585c41542a6af8ec25e6c819a03766e
&xl=249495052834
&dn=survivorlibrary.com_en_all_2024-09.zim
&as=http%3A%2F%2Fdownload.kiwix.org%2Fzim%2Fzimit%2Fsurvivorlibrary.com_en_all_2024-09.zim
&tr=http%3A%2F%2Ftracker.openzim.org%3A6969%2Fannounce
&tr=udp%3A%2F%2Ftracker.openzim.org%3A6969%2Fannounce%0A
&ws=http%3A%2F%2Fdownload.kiwix.org%2Fzim%2Fzimit%2Fsurvivorlibrary.com_en_all_2024-09.zim
&xs=http%3A%2F%2Fdownload.kiwix.org%2Fzim%2Fzimit%2Fsurvivorlibrary.com_en_all_2024-09.zim.torrent So it is included as well as This doesn't change the situation though:
The problem being that under certain undetermined conditions, the URL is not followed and apparently retried over and over. It is now important to note that I also saw MB respond with |
I could eventually reproduce and understand what happens. See transmission/transmission#7227 So Transmission only stores the original webseed URL (which makes sense) and then makes all its range requests to it (following the redirection), so the mirror gets the range request and answers it properly. So from the User's POV, it works as expected. The problem is that we (our mirrorbrain) stays in the middle of this conversation and it pollutes our log (because it's a lot of requests and scles linearly with the file size) Main issue with this is that we count Unless Transmission agrees that the current behavior is not the proper one, we should include a flag in the logs if there is is a range request header and exclude those from matomo. |
After some investigations, it appears that the current behavior is the following:
@kelson42 WDYT ? |
While looking at the mirrorbrain logs, I found a single client in Germany to be constantly sending requests to a ZIM file.
302
response to a ZIM (as is in this case) is normal. MB sends aLocation
header to the most appropriate mirror.Transmission/4.0.5
is a bittorrent client.as
field (fallback).I don't know what to do. @benoit74 @kelson42 ?
The text was updated successfully, but these errors were encountered: