Archived

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

Firon

µTorrent 1.4.2 beta 435

Recommended Posts

Yeah it's Azureus and it looks fixed in the Az beta versions

BUGFIX: Core | Fix bug in crypto stream that could lead to corruption [Parg]

Now we wait for the next Azureus stable (and maybe the next uTorrent stable will come after that ?)

Share this post


Link to post
Share on other sites

Right. BTW - I heard ludde may be fixing some bypass for it already. I believe disabling PE helps since it it reduces significantly the amount encrypted messages coming from Azureus to uT.

Share this post


Link to post
Share on other sites

Is it possible that utorrent can add the following code:

Read Peer Client;

If Peer Client is Azureus_Client_Version_with_the_problem

Then Turn Off Encryption for that Peer

Else Continue;

Share this post


Link to post
Share on other sites

yeah, but still not all people get their apps updated all the time, i still see people using utorrent 1.2, and updating utorrent is not that big of a download or a mess to reinstall :P

Share this post


Link to post
Share on other sites
outgoing?

I thought the problem is the incoming traffic...

Yes but when you download' date=' I believe YOU initiate the connection to other peers, and depending on your protocol (PE or not), the remote peer answer and sends the data.[/quote']

NO... The outgoing traffic has nothing to do with the incomming. When the incomming season is initialized then all the traffic is no encrypted.

Share this post


Link to post
Share on other sites

It's really a good workaround because sync can be lost for many reasons. What happens is that when sync is lost, the last chunk received is bad. So what µTorrent does is discard the last received chunk, thus reducing wasted data and preventing a hashfail.

Share this post


Link to post
Share on other sites

I thought hash-checks are done per-block (chunk) and not per piece ?! aren't they ? If so - this would have come naturally and not as a by-pass.

Share this post


Link to post
Share on other sites
Yes but when you download, I believe YOU initiate the connection to other peers, and depending on your protocol (PE or not), the remote peer answer and sends the data. If you do not initiate Encrypted protocol, the peers will keep to legacy protocol for ALL your downloads. For seeding/UL it is a different story, but this is not your problem... :P

No... µTorrent accepts encrypted connections regardless. Any connection (local or remote) will have to go through a handshake, and if the correct handshake is made (lol secret handshakes...), the connection gets encrypted. It doesn't matter who initiates the connection. At least that's my intuitive understanding of it.

Share this post


Link to post
Share on other sites

If an incoming connection comes in as encrypted, it's encrypted regardless. You have no control over it. Also, if you have DHT or PEX on, you may still make outgoing connections to PE-enabled peers, because they can propagate a PE flag through them to tell other clients to make outgoing encrypted connections to them.

Hence, turning it off is summarily useless. :P

Share this post


Link to post
Share on other sites
I believe disabling PE helps since it it reduces significantly the amount encrypted messages coming from Azureus to uT.

I said *reduces* not eliminates. And yes, canceling PEX and DHT as well - may reduces it some more.

Also, if you have DHT or PEX on, you may still make outgoing connections to PE-enabled peers, because they can propagate a PE flag through them to tell other clients . :P

In the event of PE=disabled - I'm not sure it should be so. It you initiated the PEX - you should NOT use PE.

And, iIt is a by-pass, not "cure". It helps me .

Share this post


Link to post
Share on other sites

If you turned off PEX and DHT (and did this -before- you started the torrent), then you won't make outgoing encrypted connections, but if you didn't, you will.

Share this post


Link to post
Share on other sites

On a ~5000 peers' swarm (SG1 ... ) you can leave them off :P

and, as I mentioned, I think contacting other PEX/DHT should comply to your disable flag too...

Share this post


Link to post
Share on other sites

I disagree. I had a long argument about this in the IRC channel and it's just not gonna happen, there's absolutely no point to comply to you disabling it.

Share this post


Link to post
Share on other sites
On a ~5000 peers' swarm (SG1 ... ) you can leave them off :P

and, as I mentioned, I think contacting other PEX/DHT should comply to your disable flag too...

People who are throttled shouldn't have to suffer because you got encryption turned off.

Share this post


Link to post
Share on other sites
On a ~5000 peers' swarm (SG1 ... ) you can leave them off :P

and' date=' as I mentioned, I think contacting other PEX/DHT should comply to your disable flag too...[/quote']

People who are throttled shouldn't have to suffer because you got encryption turned off.

I got it on untill yesterday. The only reason to set it off - is bugs, and thus many hash fails (Az).

I'm one of those throttled ones, you want me to suffer? :P

No, I don't. So I suggest you push on releasing the hash-bug by-pass / optimized version ASAP... I promise to turn it back ON again then... :)

Anyway - my poor 96K UL will not help you much... :P

Share this post


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