µTorrent 1.4.2 beta 435

[rafi 194]

Still kinda confused after reading the different type of Protocol Encryption

The purpose of this function is only to prevent throttling of p2p traffic by ISP right?

right!

[geezer 0]

If I don't think I'm being shaped, how dumb is it to go ahead and enable handshake encryption (with fallback)? Does handshake fallback add a lot of overhead?

How effective is handshake-only encryption? Can some/most ISPs already spot the other protocol messages?

[sektor 0]

One possible bug that I've found in this build and the one previous was if you select "Activate window when adding file" it does not work. Specifically, clicking on a torrent to download and open I would expect uTorrent to pop up in front of all other applications. Instead, what happens is that it just flashes in the taskbar (even if it was minimized to tray) but doesn't come out in front of all other windows. Maybe I have the options set wrong though so that it's conflicting with something else.

Yup, i noticed that too.

[skynetman 0]

I think that peer exchange should be enabled by default without any option to disable it. What's the purpose in disabling it?

Same thing for encryption. The final version should always accept standard and encrypted connections. There should be only one option IMHO: enable ALL traffic or not.

In fact encryption has always to be enabled on one side, else it is not useful. If i am using a provider that limits torrent and want to bypass it, i enable encryption but other peer must have already enabled it. So hanshaking should always use encrypted connections, while encryption on data would be used only by the ones that need it.

Right?

[nightshifted 0]

Would someone be so accommodating as to post a link to an explanation of Peer Exchange? My web search talents are nil and usually lead only to red herrings, and this was no exception. Thanks for any assistance.

[geezer 0]

Same thing for encryption. The final version should always accept standard and encrypted connections.

That's already how it works. The only thing the settings control is whether it attempts it on outgoing connections and whether it is mandatory. Incoming encryption is always accepted (provided the implementation is compatible, of course).

Disabled: does not encrypt outgoing connections, but will accept encrypted incoming connections

[Firon 3]

durerca: it's always done that.

jhn195: basically, yes.

geezer: you should only enable it if you're explicitly testing it, else you're gonna get a lot of overhead increase. And neither of the modes can be spotted at the moment, I think...

skynetman: it's a beta, PHE is ONLY FOR TESTING right now. In any case, it may be better to NOT have it on by default. Technically you don't have to turn it on to be useful, because Disabled mode always accepts incoming encrypted connections (unless you turn off accept legacy incoming connections). The control only chooses how YOUR client handles your outgoing connections, not incoming (except Force Legacy, which disables it altogether)

And PEX was turned off by default by mistake. It should be allowed to disable it because you may not want the overhead associated with it, or any other number of reasons. Just like letting you turn off DHT.

[infirmus 0]

Would someone be so accommodating as to post a link to an explanation of Peer Exchange? My web search talents are nil and usually lead only to red herrings, and this was no exception. Thanks for any assistance.

This azureus wiki page has a good explaination:

http://azureus.aelitis.com/wiki/index.php/Peer_Exchange

There is a thread here that has a lot of discussion about it too:

http://forum.utorrent.com/viewtopic.php?id=2407&p=1

[Firon 3]

Basically, the two peers tell each other that they support PEX, then exchange their entire internal peerlist with each other.

[durerca 0]

Firon, is it possible to change the behavior of the activate window option so it will force uTorrent to focus it's window in front of all other apps? I'm not sure if the majority would want this but in my case, I would prefer it that way.

[skynetman 0]

@Firon: so if someone wants from me data ENCRYPTED, does my client always accept?

Better to add OUTGOING to options to make it clear

[Firon 3]

Yes, unless you specifically set it to "Force Legacy Mode", or turn off "Allow legacy incoming connections", it will always accept encrypted connections (full or handshake, doesn't matter)

[slimy 0]

Great news

[Moitah 0]

Maybe something like this would be easier to understand:

You can play with the wording, but the main idea is to separate it into Incoming/Outgoing options.

EDIT: And another one, I'm not sure if I like the way it looks as much as the first, but it allows more flexability for choosing different combinations of incoming connection options (e.g. no encryption + handshake only for those paranoid about CPU usage):

[skynetman 0]

Yes, a lot better

Under "incoming connection" write IF U CHANGE THIS U WILL REDUCE YOUR DOWNLOAD SPEED TOO or pop up an alert

just in case anyone wants to try

[nightshifted 0]

Infirmus, Firon, thanks for explaining. I don't follow why the private=1 infodict key should disable Peer Exchange for that torrent, though.

The thread at http://forum.utorrent.com/viewtopic.php?id=2407&p=5 to which Firon pointed veered off-topic into client ID spoofing, and Silverfire closed it. Maybe the posts that got in before it was closed will answer my remaining question.

[Stan 1]

Feature: Protocol Encryption (compatible with future azureus)

This feature at least!! thanks!

[HoochieMamma 0]

Will Peer Exchange be enabled by default in the next stable release? I'm also assuming it only works with other 411 clients right? And will there be a notification of PEX being enabled under "Tracker" in the "General" tab?

[Ultima 7]

@nightshifted: When someone sets the private flag, they essentially want the tracker to be handing out the peers, not the clients. Peer Exchange obstructs that. Even though it's unlikely, if some peer managed to get into a private swarm, he would be allowed to stay in the swarm because of Peer Exchange. If the client only kept the peers reported by the tracker, the "alien" peer would be dropped out of the swarm sooner or later (without Peer Exchange), and that's the kind of behavior that should occur (or that's how I see it at least).

@HoochieMamma: I'd expect it to be enabled by default, since Firon said it being disabled by default was a mistake. And yes, Peer Exchange currently only works with other µTorrent v1.4.1 beta build 411 clients, but it will work with Azureus in the future, I believe.

[HoochieMamma 0]

Ahh cool cool, what about BitCOmet users? Will PEX work with both Azureus and BitComet clients?

[Ultima 7]

Don't know, but I'd venture a guess and say no, since BitComet hasn't released their specs, and I doubt ludde feels like reverse engineering another protocol for rather limited gains.

[HoochieMamma 0]

Ah ok, all I would wish for now is a Azureus compatible DHT implementation (In conjunction with the BitComet/Mainline one) and I wouldn't need to use trackers anymore

[Ultima 7]

Still in the works, as you can see here.

[HoochieMamma 0]

Alright! I didn't even notice that. I thought there wasn't any interest in it yet.

I also like the UDP and magnet link features

[Klaus_1250 0]

In the Peers view, i see again my WAN IP and my LAN IP

Same here...

I don't follow why the private=1 infodict key should disable Peer Exchange for that torrent, though.

If you exchange peers through Peer-exchange, people can bypass the Tracker for peers, making the torrent non-private.