Crypto Tracker Extension

[MoJo]

Will uTorrent support the Crypto Tracker extension found inside the current Azureus 2.4.0.3 betas? For more info this is a qoute from the Azureus WiKi explaining this feature:

Tracker Extension

a client may append the following parameters to a HTTP GET:

* supportcrypto=1 which means a peer can create and recieve crypto connections

* requirecrypto=1 which means a peer only accepts/creates crypto connections

* cryptoport=X in combination with port=0 which tells the tracker the port X on which the client is listening on as usual, but prevents the tracker from handing out a valid IP/Port combination if he doesn't support the crypto extension. This is only valid in combination with requirecrypto=1. cryptoport is not mandatory, a client may choose to use the port parameter as usual if it accepts legacy connections as a fallback measure.

a tracker response when neither flag is set: the tracker will return IPs/Ports as usual but omit peers that signaled requirecrypto

a tracker response when the supportcrypto flag is set: in addition to the normal peers list (or string in the compact=1 case) an additional crypto_flags string which contains a bytearray in the same order as the peers list is sent. 1 means the corresponding peer requires crypto connections 0 means the peer supports and prefers classic BT

a tracker response when the requirecrypto flag is set: in addition to the normal peers list (or string in the compact=1 case) an additional crypto_flags string which contains a bytearray in the same order as the peers list is sent. 1 means the corresponding peer requires crypto connections 0 means the peer supports and prefers classic BT. The tracker should try to achieve the numwant limit with peers that flagged requirecrypto or supportcrypto first and only add non-supporting peers if no others are available.

Azureus supports this from 2403 B55+

[Game90]

i dunno about this extension...it seems to make things more complicated and doesnt really have much benefit.

[Ultima]

Meh, I don't really see a need -- clients that don't support encrypted connections can't connect to people who disable legacy connectionsor force encryption anyway.

[DreadWingKnight]

I consider this to be a useless extension that is simply a waste of bandwidth on both the client and tracker side.

[justbest]

Hi.

I'm pushing this topic up.

Because I'd like to see this Feature in future Versions also in µtorrent. I've found out that BitTornado also sends the requirecrypto and supportcrypto flag.

I don't think this is waste of bandwidth in times of broadband. Because if more Clients send that flag you can set up your tracker only to accept this flags and only response that ips that also have this flag. As of your needs (the tracker ones) you can for example deny ppl without that cryptoflag to share with each other. Or you can prefer them.

You can also SAFE bandwidth:

If you have set up your client "requirecrypto=1", you set up your client only to accept connections with protocolencryption. So it would be senseless for the tracker to response peers that don't at least send "supportcrypto".

As of µtorrent 1.8 sends the whole ipv6 adress to the tracker... I also don't see any guiltiness to the argue "useless traffic".

I claim to add the crypto-flags into the µtorrent-announce.

Regards, justbest

[Firon]

The main problem with this extension is that no tracker really supports it.

[Bonzo]

I know of one tracker that does support it. uTorrent users there find themselves as a disadvantage as a result.

Where a tracker supports this extension protocol, it assumes that no client supports encryption unless it says so. If a peer tells the tracker that it requires encryption, it is hidden from peers using uTorrent. The rationale is that if you don't support encryption (or say that you do), peers requiring encryption are none of your business. There may be seeders but a downloader using uTorrent may never see them.

For example, let's say that a user of Azureus is the only seeder on a torrent and requires encryption. A downloader using uTorrent joins the swarm having seen a seeder listed on the web site. uTorrent is then told by the tracker that there is no seeder. The uTorrent peer may eventually get an incoming connection attempt from the seeder. If he's set up to accept incoming connections, he'll connect after a delay, else he's short on luck and will never connect to the invisible seeder.

Encryption provides a measure of privacy. The extension protocol goes further to protect privacy and encourage encryption. I think that it's in everyone's interest if uTorrent is seen to show some support for this too, despite the tracker protocol being invented elsewhere. Would it hurt to send a couple of flags to the tracker and get some extra privacy? That would, in turn, encourage more trackers to support the protocol.

[jewelisheaven]

http://bittorrent.org/beps/bep_0008.html

[blackflag]

For your information, www.ipernity.com has released its home made tracker which support this extension.

http://www.ipernity.com/blog/team/87669

ipernity even enables you to share your torrent within a private community (family, friends...).

[Fiamma]

I know and belong to two private lossless trackers that have implemented the encryption protocol extension mentioned here.

We cannot be seen by Azureus seeders very well, usually a delay of quite some time before the AZ client asks for a new peer list and sometimes even then there is a problem connecting and I am green ported.

Az users are complaining that they can't connect to utorrent clients, thereby slowing down their upload swarms, extending the time they need to seed, etc.

Further, on one of the trackers, utorrent accounts for 60% of the clients used by the active members and AZ nearly accounts for the rest. There are only a few bit tornado clients and some rtorrent and transmission clients.

The encryption protocol is therefore not useless and the lack of utorrent's ability to send the information is hurting utorrent users on these trackers.

I would hope that the dev staff here revisits this issue.

[thelittlefire]

I still don't see this proposal/extension at http://bittorrent.org the official homepage for maintenance of the bittorrent protocol . . .

... lack of ability to send the information hurts... Would this only be the case if the peers NEVER connected? Are you saying it would be BETTER or FASTER if uTorrent supported this extension? It is wise to defer to DWK in the matters of trackers...

Is it possible many trackers have adopted this since the last time the issue was visited--yes. Sufficient numbers/appeal to warrant adding overhead without much gain--possible.

[Fiamma]

It would be BETTER if utorrent supported this extension. Azureus clients cannot see utorrent clients if the Azureus client is using the Require encryption setting until they update and ask for a new list of peers. As it is when they do update the utorrent client is at the end of the list, Azureus clients get RC flagged first then SC flagged and then us, if we are green ported, on a tracker that has implemented the extension.

utorrent has the enable encryption setting but is not sending that info to trackers who have implemented the extension.

It's like living in a black hole when it comes to trying to get a decent download speed until the Az clients ask for a new peer list and see us. There is no such thing as joining a swarm and connecting to Az users right away on any tracker implementing the extension.

Perhaps I should mention that I'm the admin on a tracker that is having problems with utorrent clients not sending the encryption info.