improve torrent error logic

[trim21]

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.

[trim21]

for example, this is a private tracker torrent:

and I hope this can be consider error.

[trim21]

And I can send a pr to impl this

[qu1ck]

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.

[trim21]

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 isBackup: false and others have isBackup: true, and have a nextAnnounceTime: 0, even they are all tier 0 trackers.

---

10000 torrent with one extra field would just add 10kb to network traffic...

[trim21]

and I'm gussing, if there are no network errors, transmission won't announce to next tracker...

transmission/transmission#890 (comment)

[qu1ck]

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?

10000 torrent with one extra field would just add 10kb to network traffic...

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.

[trim21]

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?

api will always order trackerStats in the same order with tracker url in torrent's announce-list, the "bump" is internal only.

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.

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.

[qu1ck]

api will always order trackerStats in the same order with tracker url in torrent's announce-list, the "bump" is internal only.

If that's the case then I would welcome a change that checks for first non-backup tracker instead of simply first tracker.

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.

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:

1. Use transmission remotely on internet seedboxes and may be on metered connections.
2. Use transmission on raspberry PIs or small appliance type NAS devices that share similarity with toasters not just in external dimensions but also in CPU power. I had one such device that would literally stall on downloads/seeding because all of it's brains were busy generating json for the API response instead of handling p2p comms. That was even more of an issue on earlier transmission versions that were not properly multithreaded.