Community Forums

Many retracker-users are missing the uTorrent ability to scrape a few trackers simultaneously.
This helps to communicate with not only the main(first) tracker in the list but with the other trackers, especially with 'retrackers'.
'Retrackers' are the secondary trackers that correspond IP's of the peers in the local regional net or the provider's net or smth else.
The normal flow of operation must be asking the first tracker and than the next trackers in list.
Such a way a peer is still connected to the main tracker (& gets stats, scrape, rank, peers list, etc.), but is getting the local IP's from retracker.
For ex., such IP's may view as local 10.xxx.xxx.xxx, that is unavailable from the main external tracker and may be VERY fast.
In short, this tracker problem is one of the most complained in the russian forums, compelling to swap the client.

Thanx.

Sorry, I don't understand the meaning of the answer.
p.s. DHT does not help in getting the internal IP's. PEX is not a helper without link to the internal recepient.
p.s.2 If uTorrent is communicating with all the trackers from a list - why Vuze not? It's good.

Edited by: Gambit on 03.11.2009 13:13

No, no, no. This won't help.
I think you dont understand what is retracker for.
Some providers give to the users 2 sublan IP's - internal & external
External IP's traffic is not fast and sometimes coasts a lot.
Internal IP's traffic is unlimited, very fast and free.
So such peers are interested mostly to get internal IP's to connect.
But the tracker sees only the external IP and corresponds this to the peers.
To solve this problem were created 'retrackers':
The main tracker inserts into the torrent (only to such users, based on their profile)
multi-tracker info - 1 URL for itself & 2 URL for retracker.
Retracker is a constantly running server program that cashes only the info-hashes
of any requests and the IP's, then corresponds the known IP's to the next requesting peer.
As the retracker is placed into the local IP-space, it corresponds ONLY the local IP's.
There even may be used an IP-filter inside retracker to avoid communication with non-local peers.

The second case of using a retracker is a regional IX or ExchangePoint of traffic.
Some regional providers agree to exchange the traffic for free and unlim.
So traffic between such users is free and very fast. Such users also point in their
profile on the national-wide tracker that they do live in that region and do want to use the retracker.
Than they always download specially prepared the multi-tracker torrent, but bump into the problem - while with uTorrent everything is pretty good (they get a connection both with the main tracker and retracker), Vuze ONLY connects to the first (main) successful tracker and doesn't leave any attention to the next tracker (f.e. retracker), thinking of it only as a possible backup tracker. In the other case when the main tracker is temporary down, Vuze connects to the retracker and never returns to the main tracker ( - statistics, ect.) as the retracker is on.

Regarding plugins like LAN peers finder - this won't help, unfortunately.
First of all that the most people use uTorrent
Second - providers' IX-ring is not a LAN, its structure is uncommon and hidden. Only users can know the peering agreements between the providers.
Also such peers are actively using the IP-filters - so nobody externally may tell via PEX & DHT about known IP's from the regional range.

p.s.
I understand that this may be hard to dig in, to some people it may look strange, but it's a reality.
A simple change in tracker communication routines may solve the problem.
Many trackers relay on such a client-behavior (like uTorrent) and fail if not.
Hope, I've explained clear.

Edited by: Gambit on 03.11.2009 14:57

uTorrent and BitTorrent simply make the announce session not only with the first successful tracker but with all the list. That's that.
We even won't need to understand what are that 'retrackers' for if such a client-behavior is implemented.

Don't think so.
If uTorrent and BitTorrent become a BT-standard, Vuze must do the same and evrth will be fine.
A share of Vuze is smallest in the worldwide uTorrent/Vuze ratio, it will not make any hardness to the trackers.
Retrackers are made to be used such a way, for ex.
In short, Vuze's behavior must not differ from BitTorrent. Or Vuze becomes a non-relayable software.
Tracker's code and possibilities must not to be different according to client.

Such a thinking generally holds back a Vuze expansion.
Users prefer more tracker-compatible programs and ignore the others.
uTorrent's behavior is a standard de-facto.
Rules are for the people, not people for the rules.
Today were made:
DHT BitTorrent-compatible via mlDHT
PEX BitTorrent-compatible via core
and a lot of features from this software.
It's good, isn't it? Or it's a crime too?

I would suggest to program the following:
1) Groups of trackers are asked in rotation as in BitTorrent, each time the announce to be made.
2) Within the group each tracker is to be a backup in a case if the previous tracker is down. If the first tracker of the group is always reachable - the others are never asked.

So would be nice.