Multi-tracker handling - bug or suggestion?

[sixshot]

Not sure if this is a bug or if this is part of the feature... while monitoring the currently downloading and seeding torrents, I came across one with a multi-tracker. Every second I see a different tracker until it loops back to the first tracker entry. Looks normal, right? Well...

Because trackers are often loaded when a torrent using it is popular, wouldn't it make more sense to use one tracker and only use the next one when the previous attempt failed? I'm all for supporting the multi-tracker specs but I think having it contact all of them is more burden than it is worth.

Is this a bug? Or is this normal of uTorrent? Perhaps this should have been in the Found bug area? I dunno. Please move it if it is a bug and feel free to edit the title appropriately to reflect it.

[Firon]

It's not a bug, other clients do the same thing. The point is to get a peer list from ALL trackers (and advertise yourself to all trackers as well) so you can have the maximum possible number of peers.

[sixshot]

I thought the multi-tracker specs calls for the initial checking of all the trackers and then make judgement based on which tracker responded successfully. And from there that tracker is then used until it needs to use a fallback. Maybe I misinterpret how the specs was written (using this as reference).

I originally thought that the primary or first tracker is attempted first and foremost and use the others only when it failed to respond. I didn't know that all the trackers in a multi-tracker torrent is polled constantly. Oh well. Shows how much I know about how that part works.

[NiteShdw]

Most clients do as you say, they go through the trackers until they get one that works. The problem with that is that clients OFTEN get STUCK on backup trackers just because the main tracker didn't respond fast enough (like Pirate Bay's).

On my forum site, I'm constantly getting reseed requests for very well seeded torrents, all because they were stuck on some backup tracker with very few peers.

The FEATURE of μTorrent is that it announces to ALL available trackers and gets a list of all available peers. Believe me, I've been desperating wanting a client that does this for a long time. It is a feature because it is able to retrieve more peers than other clients that just sit on one tracker.

P.S. Each GUI update changes the displayed tracker to show the information (URL, Status, Update In) for that tracker. It is still sending announce requests at the proper (usually 30 minute) intervals. Just watch the Update In.

[chaosblade]

NiteShdw is right here. The messages sent to the tracker are very minimal in bandwidth as it is (single HTTP GET message), And the benefit is that of more peers and seeds from other trackers. Scratch another good point up in uTorrent's favor

[DreadWingKnight]

Because trackers are often loaded when a torrent using it is popular, wouldn't it make more sense to use one tracker and only use the next one when the previous attempt failed? I'm all for supporting the multi-tracker specs but I think having it contact all of them is more burden than it is worth.

Running a multitracker network myself (and probably the target of one of your downloads) and announcing to all trackers in one of the torrents configured for my network is a massive waste of bandwidth, connections and processing (to the tune of blocking up to 12 clients from starting just for the sake of announcing to all the trackers which happen to already know about you anyway and using 12 times the resources for no benefit)

I originally thought that the primary or first tracker is attempted first and foremost and use the others only when it failed to respond. I didn't know that all the trackers in a multi-tracker torrent is polled constantly. Oh well. Shows how much I know about how that part works.

You have the understanding of a proper multitracker implementation. Announcing to all trackers can end up being pretty abusive.

The FEATURE of μTorrent is that it announces to ALL available trackers and gets a list of all available peers. Believe me, I've been desperating wanting a client that does this for a long time. It is a feature because it is able to retrieve more peers than other clients that just sit on one tracker.

Actually, announcing to all torrents listed in a multitracker announce-list has previously gotten other clients banned from multitracker networks. As a multitracker network administrator, I consider this a BUG as I have in the past.

NiteShdw is right here. The messages sent to the tracker are very minimal in bandwidth as it is (single HTTP GET message), And the benefit is that of more peers and seeds from other trackers. Scratch another good point up in uTorrent's favor

I chalk up another strike because of the abuse.

[chaosblade]

Well, constantly updating ALL trackers is abusive, right. But i dont see an issu e with just getting initial peer lists from them all. In your case DWK, That would not be so helpful since the trackers are on the same network and probably share the same stats, but would allow better performance with little abuse for torrents that are tracked on different networked trackers.

[NiteShdw]

Because trackers are often loaded when a torrent using it is popular, wouldn't it make more sense to use one tracker and only use the next one when the previous attempt failed? I'm all for supporting the multi-tracker specs but I think having it contact all of them is more burden than it is worth.

Running a multitracker network myself (and probably the target of one of your downloads) and announcing to all trackers in one of the torrents configured for my network is a massive waste of bandwidth, connections and processing (to the tune of blocking up to 12 clients from starting just for the sake of announcing to all the trackers which happen to already know about you anyway and using 12 times the resources for no benefit)

I don't see how this is a "massive waste of bandwidth". Running a tracker, I'm sure you know that a single announce response is only a few KB at most. If μTorrent receives duplicate entries from two announces, it will still only connect to that peer once. Each tracker receives an announce on the normal 30 minute interval. Plus, each announce should contain a RANDOM list of peers, so sending announces to duplicate trackers should have a minimal number of duplicate peers.

I understand where you are coming from, my torrents have at least 3 backup trackers URLs just incase there are problems with one, but they all point to the same tracker. I understand that announcing to all of them will increase total traffic to the tracker.

At the very worst, every 30 minutes the duplicate tracker will send an extra few KB as an announce that may or may not contain duplicate peers.

I still fail to see the "massive waste of bandwidth".

[R1CH]

I still fail to see the "massive waste of bandwidth".

Maybe not bandwidth, but resources. If you ever run a popular tracker, you'll understand.

[Nike]

I still fail to see the "massive waste of bandwidth".

Maybe not bandwidth, but resources. If you ever run a popular tracker, you'll understand.

Don't make a jibe at Nite. He runs one of the best torrent sites ever. He knows what he talks about.

[DreadWingKnight]

You run one with three announce urls that all point to the same tracker?

A friend of mine runs a tracker with NINE announce urls.

I run a network of linked trackers with TWELVE announce urls.

The number of peers you get with ONE announce is enough to get going.

http://wiki.theory.org/BitTorrentSpecification

Just above the "Tracker 'scrape' convention" states that connecting to peers beyond 60 doesn't really benefit the downloader.

Each announce on my tracker includes 50 peers by default. 12 announces at 50 peers each is 600 peers.

That's a lot of announces and a lot of peers for no real benefit.

Honestly, in situations where trackers are hosted on providers where every byte counts, having 3X-12X the traffic because of clients that don't follow the rules is VERY bad for them.

[NiteShdw]

Honestly, in situations where trackers are hosted on providers where every byte counts, having 3X-12X the traffic because of clients that don't follow the rules is VERY bad for them.

I understand your point. But you'll notice that the original BitTorrent specification doesn't have ANY support for multiple announce URLs. The "announce-list" dictionary was invented by the author of BitTornado. There is no official spec. So, in reality, there are no 'rules', just norms.

It looks like 1.1.6 "fixes" this, which I'm actually pretty annoyed with.

[ScubaSteve]

i dont think they have taken it away, It still contacts all trackers to receive the peer lists, you just dont get the annoying thing of the tracker url changing every second.

[sethg]

If a tracker provider puts up multiple announce URL's partly to perform a crude form of load sharing, we are completely defeating their intentions by contacting all trackers. If all clients did this, the load on every tracker would be the same as if there only a single tracker. I think it is best to pick a single tracker, but the hard part is deciding which one to go for. Maybe DreadWingKnight has some suggestions as to the best way for a client to handle this.

From the client's side, we don't want to wind up on a backup tracker with very few peers. We also don't want to abuse the resources of a multi-tracker network that someone has put together for the benefit of their users. DreadWingKnight, what would you consider reasonable client behavior in this environment?

[DreadWingKnight]

Honestly, in situations where trackers are hosted on providers where every byte counts, having 3X-12X the traffic because of clients that don't follow the rules is VERY bad for them.

I understand your point. But you'll notice that the original BitTorrent specification doesn't have ANY support for multiple announce URLs. The "announce-list" dictionary was invented by the author of BitTornado. There is no official spec. So, in reality, there are no 'rules', just norms.

It looks like 1.1.6 "fixes" this, which I'm actually pretty annoyed with.

The fix that 1.1.6 adopted for multitracker is following the rules defined at http://bittornado.com/docs/multitracker-spec.txt (John "TheSHAD0W" Hoffman's Multitracker Specification document) for per-tier processing, while simultaneously announcing to all tiers. Each tier will have 1 tracker being announced to each cycle.

It's not following the specification to the letter, but it's playing IMMENSELY nicer than it was.

Be as annoyed as you want. I won't tolerate the amount of tracker abuse that was being generated by the old way uTorrent was doing multitracker AT ALL on my network.