Jump to content

µTorrent 1.4.2 beta 435


Firon

Recommended Posts

  • Replies 1.1k
  • Created
  • Last Reply

Top Posters In This Topic

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?

Link to comment
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.

Link to comment
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?

Link to comment
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
Link to comment
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.

Link to comment
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

Link to comment
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

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...