Archived

This topic is now archived and is closed to further replies.

Firon

µTorrent 1.4.2 beta 435

Recommended Posts

Still kinda confused after reading the different type of Protocol Encryption :P

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

right!

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

durerca: it's always done that. :P

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

Maybe something like this would be easier to understand:

ut_enc_opt_proposal.png

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):

ut_enc_opt_proposal2.png

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 :D

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.