µTorrent 1.4.2 beta 435

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.

If someone did select an option called "Activate window when adding file," why wouldn't they want it to activate? Activate to me means put itself out in front to be acted upon. It doesn't mean flash in the taskbar. That's the behavior one should see if "activate" is NOT checked. So we agree that the way this feature works currently at minimum is counterintuitive and at worst faulty.

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

Peer authentication by the client is not planned, I should know since I asked and the thread got locked as quickly as the answer came.

http://forum.utorrent.com/viewtopic.php?id=5037

There is no mechanism in the client to prevent aliens from getting in the swarm except those already in place (peer authentication by tracker using member ID) and there is no mechanism in the client to cut those peers if/once they get in.

For peer authentication by the client to work, it would require continuous or at least complete tracker scrape to get a complete list of all connected peers. That kind of behavior is disruptive to the tracker and to the torrent since it normally sends out random peer lists to each peer that requests a new list at regular interval (default is 1800 seconds or 30 minutes, I think).

It could even accelerate the PEX problem that it would try to prevent. If one peer can ask for the complete list of peers in just one scrape, it can exchange this list with aliens just as quickly. The problem that peer authentication would try to solve would create an even greater problem itself that would then require its own solution. Round and round.

I can see PEX being used in conjunction with a choker that sends not just the peer list but also the results of the choker's work regarding those peers. Good peers are kept, bad ones are cut. Good peers get TFT'ed with by many more other good peers and so on.

All in all I like it.

ML

Ultima, Klaus_1250: thanks for answering.

So, for example, let's say a torrent is on a private tracker. If someone adds an external peer manually, and there's no peer exchange going on, this external peer has a connection only to whoever added him/her. Then it's as if the adding peer had sent a copy of the torrent content to the added peer separately from the torrent, because the only participant uploading to the stowaway is the one who voluntarily added him/her (and unless he came in with some of the content, nobody is downloading from him/her). But if peer exchange is allowed, that outsider's IP:port pair gets passed around to others without the tracker's knowing it, and any member can add a stranger as virtually a full participant in the swarm.

Is it something like that, then?

Yep, that's the explanation I came up with at least =P

@Martin Levac: Peer authentication is different, and is more of a preventative measure. With peer authentication, I'd assume you wanted it to confirm with the tracker that the peer is connected, no? That's not the same. I'm not talking about peer authentication... what I was saying was that the way PEX is currently implemented (disabled when private flag detected), any outside peer that just (maybe hypothetically) happened to get into a private swarm wouldn't be able to propogate and connect to the other users as if he were an actual user of the tracker, since peers wouldn't be shared (and only gotten from the tracker). I was explaining why one would want PEX to respect the private infodict flag.

Since uTorrent respects the private flag, only the injector would bleed to this alien.

You said "If the client only kept the peers reported by the tracker,..." so I thought you were talking about a peer authentication method.

ML

Is µTorrent's PHE consider to be better then the BitVomit's PHE??

Another question, ludde, do you consider the current PHE algorithm as final?

It's not really PHE as opposed to PE now, since it's not just the headers being encrypted. And yeah, it is better than BitComet's PHE since it is truly encrypted, and is designed more thoroughly (for example, there is no standard BitTorrent handshake for ISPs to detect and block). Also, it's an open extension, unlike BitComet's, so has the potential to be adopted more widely. I'd think that the spec (I'm assuming you mean spec, since the algorithm is just RC4 encryption, which is supposed to be easy to implement) is at least close to final (if it isn't already), since it's already implemented in the betas for both µTorrent and Azureus. And I guess that's what the beta is for -- to test if it is working properly, and to see whether any changes need to be made before an official non-beta release.

@ML: Heh technically if you're not getting your peer list from any other client, then your only other source in a private torrent is the tracker (unless you manually add an outside peer yourself, but we'll discount that in this case), so that's why I said that. And yes, what you wrote in that first line was what I was trying to get at (only in a much more verbose manner xD).

Azureus doesn't have it in a released beta yet, but it's in the CVS. The one in the current beta is the old MSE spec they made.

Yes, it's better, it's not (easily?) detectable like BC, closed, and it's also fast. Also lets you encrypt all the data instead of the headers.

Firon, does µTorrent use the torrent hash as decrypt key?

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

So turning PE on will reduce DL speed? Is this for sure or just a possibility?

well, if you look it at a certain way, yes it can reduce the speed.

Not as in DL speed, but how long it takes to download the torrent.

Why? because encryption adds extra data to the data transfer.

But I believe that µTorrent's PHE is pretty light so it doesn't make much difference.

It could incur a small, very minor performance hit, but would you rather have that, or no speed at all? :|

I assume that it would only lengthen the time to completion, in cases where you max out your connection. Otherwise, your connection should be able to handle the extra data.

Yes' date=' a lot better

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

just in case anyone wants to try

So turning PE on will reduce DL speed? Is this for sure or just a possibility?

No i'm saying that disabling one type of incoming connection (referring to ENCRYPTION or not) can reduce your download speed. In fact if someone forces encryption and u refuse encrypted incoming connection u will not upload to him (and you will download zero to few bytes from him too)

It's not peer echange.

what about compact_allocation, does it work now?

Apologies if this has been mentioned already.

The advanced option "gui.compat_diropen" has been broken the last few versions for me, including this beta. I believe it last worked in one of the 1.4 betas.

Toggling this option has no effect -- attempting to change the directory in the add dialog just opens a "Browse for folder" box instead of the "old-style" open/save dialog box.

Perhaps I've missed something but I did like how it worked in the 1.4 betas -- made getting around a LOT easier since I could access the "Places" sidebar.

This client just keeps getting better and better! I'm particularly excited about the new peer exchange feature! Thanks a lot for a GREAT client!

- Fix: Improved autoload so it waits a bit if the file hasn't fully been written to disk yet.

This was my bug report, so fixing it makes me feel extremely happy. Good work!!!

Suggestion for the lazy bitfield changes: make it send HAVEs if the peer isn't interested. Preferably not all at the same time, say 1 every 0.5 seconds until the peer is interested. I just watched a peer get stuck at 99.8% and stop requesting pieces.

EDIT: Another thought, IMHO µTorrent shouldn't use lazy bitfield over encrypted connections, it's not necessary.

In the Peers view' date=' i see again my WAN IP and my LAN IP[/quote']

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.

What about the Peer-exchange disables when the private flag is set (and the option 'enabled' is off course disabled, won't it solve the problem?).

That's what it's supposed to do, and that's what nightshifted as asking for an explanation for O.o

Same problem here about the window NOT coming up in front of all others. I seem to recall having the same problem with ABC and, intermittently, with uTorrent. Minor problem, I suppose.

Thanks for the Protocol Encryption (or Peer Exchange?). Not looking a gift horse in the mouth, I hope, but the explanations about handshakes and such is going right over my head. Anybody available to translate into "blockhead" for me (and others)?

Thanks for uTorrent, it's the greatest and if PE helps to foil the evil traffic-shaping ISPs, then the world really is developing as it should.

:-)

Peer Exchange: A function that gets you a few more peers by trading peerlists around with the guys you did connect to. I suppose I don't have to say how knowing about the existence of a few more peers helps you, especially in crap torrents.

Protocol Encryption: A function that encrypts your BitTorrent data. That way, maybe you can fool those "evil" traffic-shaping ISPs.

Probably is just a cosmetic flaw, but µtorrent doesn't show anymore "listen error" message in the statusbar when the port is already taken by another application.

Peer Exchange: A function that gets you a few more peers by trading peerlists around with the guys you did connect to. I suppose I don't have to say how knowing about the existence of a few more peers helps you, especially in crap torrents.

Protocol Encryption: A function that encrypts your BitTorrent data. That way, maybe you can fool those "evil" traffic-shaping ISPs.

Thanks, Kazuaki. So now it's clear that those two PEs are not the same thing. Now we need some guidance as to how to configure those preferences, although I realize now that this is a discussion among beta testers, so I'll be following this as best I can. Carry on and thanks to all.

:-)

Yep, we usually write Peer Exchange as PEX, which would reduce the confusion =P

Peer Exchange doesn't really need configuration, and as for Protocol Encryption... the first post in the thread explains each option =]