-
Notifications
You must be signed in to change notification settings - Fork 27
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
improve torrent error logic #196
Comments
And I can send a pr to impl this |
I'm not sure that would be an improvement. I'm assuming for private tracker torrents vast majority have only one tracker and for rare cases where they have multiple they are effectively the same and act as backups. In this case "one failure = error" logic does not make sense. And there is also the downside of having to add another field isPrivate to the list of always pulled fields which increases network traffic. |
It's true they should effectively the same, but in practice, not all tracker return same response. because transmission may not announce to some trackers. in this case, transmission will consider 2 trackers "backup", and won't annoucne to them in api, you can find one of them has 10000 torrent with one extra field would just add 10kb to network traffic... |
and I'm gussing, if there are no network errors, transmission won't announce to next tracker... |
That same comment you linked says that in case of failure next successful tracker in the same tier will be tried and bumped to the top if it succeeds. So it's enough to check the first one, like current implementation. Unless the api does not reorder the tracker list in the response?
Its json, it's a lot more than 1 byte per entry in plain text and even gzipped it would be at least 3-5 bytes. |
api will always order trackerStats in the same order with tracker url in torrent's
Don't quiet understand why you care 5 bytes in network traffic... 160 torrent is already 28kb, so even 10000 torrent would be 1750kb. so even 50kb, would be and roughly 2% increase, it's even less than 1/1000 after gzipped. Also I think most people run transmission (and webui) in internal network. |
If that's the case then I would welcome a change that checks for first non-backup tracker instead of simply first tracker.
That part I'm planning to improve at some point on transmission side because the api currently does not support querying specific subfields of heavy composite fields like trackerStats. That field alone takes up majority of a typical response. Once that is fixed every single field will be not 1-2% extra but more like 5-10% extra. Besides there are a lot of people that:
|
Let's say, I have two kind of torrents. BT(public tracker) torrents and PT(private tracker, with
isPrivate=true
in api) torrents,.I hope to imporve torrent error logic, so is a torrent is private, any tracker in pt torrent return a message is consider error. And if it's not private, all trcker in bt torrent return a message is consider error.
The text was updated successfully, but these errors were encountered: