Opened 9 years ago

Closed 8 years ago

#4501 closed Bug (invalid)

throttle back to single scrape if tracker only gave one response to multiscrape

Reported by: reardon Owned by: jordan
Priority: Normal Milestone: None Set
Component: libtransmission Version: 2.33
Severity: Minor Keywords: patch_needed
Cc:

Description

I have noticed a problem with several private trackers using relatively older tracker software, where they will reply to a multiscrape with info for only the first info_hash in the request. Transmission should include at least the simple heuristic to disable multiscrape when a tracker responds with only one "files" entry to a multiscrape.

Change History (13)

comment:1 Changed 9 years ago by reardon

This really needs some attention...I'm willing to come up with a patch but need a little direction. The interaction between trackers' and tiers' data structures and logic are a bit confusing to follow in code, so I've been unsure where I should put state info like "this tracker failed multiscrape, revert to single scraping, try multiscrape again in 24 hours".

Thoughts?

comment:2 Changed 9 years ago by jordan

Reardon, thanks for offering to dig into this. It's greatly appreciated :)

Just off the top of my head, this is what I would try first:

Try adding a field int requested_row_count; to the tr_scrape_response struct. Initialize it in announcer-http's tr_tracker_http_scrape() and announcer-udp.c's tau_scrape_request_new().

In announcer.c, try adding an int maxScrapeCount; to the tr_tracker struct (Yes, I know libtransmission needs to pick a single naming scheme ;), initialize it to TR_MULTISCRAPE_MAX in trackerConstruct(), copy it (just like seederCount et al) in copy_tier_attributes_impl(), and use it as the upper bound in multiscrape() (currently TR_MULTISCRAPE_MAX is the upper bound).

In announcer.c's on_scrape_done(), the request count and the response count could be compared. If the response count is lower, we could set currentTracker->maxScrapeCount accordingly. Of course maxScrapeCount should never be lower than 1.

comment:3 Changed 9 years ago by jordan

any news? :)

comment:4 Changed 9 years ago by reardon

Sorry, swamped for the moment, but if still open I will engage on this after Nov 7.

comment:5 Changed 9 years ago by livings124

reardon: ping

comment:6 Changed 9 years ago by reardon

Again, sorry, this needs 2 days to do implement and test and I haven't had that block of time.

comment:7 Changed 9 years ago by livings124

reardon: any status update here?

comment:8 Changed 9 years ago by reardon

Sadly, no. No time for hacking on this IRL.

I have a simple hack for now that solves the problem for me, but it is clearly not production worthy.

FWIW, in multiscrape() [announcer.c] I just added a check for "known bad" trackers and do not allow them to package multiple scrape requests together. The "known bad" list of tracker urls is fetched at init from a flat file.

comment:9 Changed 9 years ago by jordan

  • Severity changed from Normal to Minor

comment:10 Changed 8 years ago by jordan

  • Keywords patch_needed added

comment:11 Changed 8 years ago by jordan

reardon, do you have any plans to implement this?

comment:12 Changed 8 years ago by reardon

Honestly, none. I have a local hack to switch to single-scrape based on tracker name. I have not run across newer trackers that fail multiscrape, so I'll assume the ecosystem will handle this. But it reminds me of another multiscrape issue about which I'll open a bug for discussion.

comment:13 Changed 8 years ago by jordan

  • Resolution set to invalid
  • Status changed from new to closed

If there's no demand for this feature, and trackers all seem to support multiscrape noawadays, then let's close this ticket out ;)

Note: See TracTickets for help on using tickets.