µTorrent Community Forums

redguard

Member

Re: Better encryption

I'm watching closely the evolution and, hopefully, the resolution of this issue since that will make me, and many, very happy.

Clinch

Member

Re: Better encryption

wow I just tested it and its working no throttle!!

redguard

Member

Re: Better encryption

Tested what? Deluge? Well, of course it works, but here we are trying to find [and by find I mean persuade the developers to 'bend the rules'] the causes of why Deluge is working and putting these mechanisms in next-gen client [here uTorrent].

And I just can't wait to read tomorrow's report.

exorcista

Member

Re: Better encryption

well..
did any1 anylized this ?
http://rapidshare.com/files/71061974/utorrent.rar.html (both programs there)

Greg Hazel

BitTorrent Developer

Re: Better encryption

well..
did any1 anylized this ?
http://rapidshare.com/files/71061974/utorrent.rar.html (both programs there)

We did. We need more logs

Specifically, we need logs of uTorrent and Deluge with the exact same settings (and a record of what those settings were) in these configurations:

* Forced (and incoming encrypted only)
* Enabled (and incoming encrypted only)
* Enabled (and incoming encrypted optional)
* Disabled

Run each until their speed levels out, with maximum connections of 20.

Clinch

Member

Re: Better encryption

deluge is open source cant you just open up the source and look

Greg Hazel

BitTorrent Developer

Re: Better encryption

deluge is open source cant you just open up the source and look

It is nothing obvious or intentional about the implementation. There's some different in the network behaviour or packet boundaries.

Clinch

Member

Re: Better encryption

I'd give you guys logs but I have wireless and wireshark doesn't work with it.

Greg Hazel

BitTorrent Developer

Re: Better encryption

I'd give you guys logs but I have wireless and wireshark doesn't work with it.

Have you tried turning "Promiscuous Mode" off before you capture?

Clinch

Member

Re: Better encryption

no but doesn't that mean i only capture received packets. I thought outgoing packets are the important stuff.

Saribro

Member

Re: Better encryption

I've tried wireshark with my wireless, works perfectly fine if you turn of promiscuous mode.

Greg Hazel

BitTorrent Developer

Re: Better encryption

no but doesn't that mean i only capture received packets. I thought outgoing packets are the important stuff.

Promiscuous Mode means you'll capture packets that are not addressed to you - so other traffic on the wifi network. If you turn it off you will still get packets to and from you, which is all we care about here.

redguard

Member

Re: Better encryption

Any news?

Clinch

Member

Re: Better encryption

hm, this new version 0.5.7, my upload is getting throttled but not download.

redguard

Member

Re: Better encryption

For me 0.5.7 or 0.5.7.1 crashes like hell.
UPC is going down.
The whole world is going to hell. I'd better get my supply of Chardonnay and die like a Frenchman.

Last edited by redguard (2007-12-02 13:14:22)

Clinch

Member

Re: Better encryption

ok now download/upload is throttled.

Switeck

Member

Re: Better encryption

They may be throttling based on line activity or some other nebulous concept...like incoming connections/outgoing connections, etc.

funchords

Member

Re: Better encryption

I have three ideas...

#1:

Since BitTorrent messages are prefixed with the number of bytes (e.g. 17 TCP payload bytes for a BT Request), would adding some "throw-away" bytes to the end of the packet break anything?  Something like

::START::
REQUEST
REQUEST
NOOP
::END::

SIMILARLY

::START::
NOOP
UNCHOKE
::END::

My rationale is that some of these devices are counting bytes, looking for sequences such as INTERESTED, UNCHOKE, REQUEST.  The "encryption" is just a cipher, so their byte-counting scheme works.  I suspect that if packet sizes and sequences became a little less predictable, their layer-7 stuff will have to work harder.

#2:

Only request pieces from seeders when those pieces are not available from leechers.  This will promote two-way traffic.  One "fingerprint" of P2P uploading that these devices seek is the one-way connection. 

#3:

Use local throttling to keep up/down ratio within 10% of each other.  This will keep the two-way traffic going as long as possible, and avoid the situation where the download completes with a ratio of 0.25 and the person has to try and seed for a long time.

Greg Hazel

BitTorrent Developer

Re: Better encryption

#1:

My rationale is that some of these devices are counting bytes, looking for sequences such as INTERESTED, UNCHOKE, REQUEST.

Deluge certainly does not do anything like this. Azureus implemented something to this effect speculatively, but I'd like to see a case where it helps first - it complicates the protocol for the future.

#2:

Only request pieces from seeders when those pieces are not available from leechers.  This will promote two-way traffic.  One "fingerprint" of P2P uploading that these devices seek is the one-way connection.

Again, in this case Deluge is being limited on download not upload. You're right that the Sandvine hardware targets seeders. uTorrent makes some effort to request pieces from leechers instead of seeds, simply because seeder bandwidth is considered to be more valuable. This should really be rare-piece bandwidth, but oh well

#3:

Use local throttling to keep up/down ratio within 10% of each other.  This will keep the two-way traffic going as long as possible, and avoid the situation where the download completes with a ratio of 0.25 and the person has to try and seed for a long time.

From your description it sounds like this would drastically slow down networks, or at least the individual's download time. The person does not have to seed at all after the download is complete if no one is enforcing their ratio...

jewelisheaven

Member

Re: Better encryption

As a concerned user for the future of the protocol, i urge ANYONE trying to suggest uT is inferior (where one is shaped and the other is not) to try specifically multiple download swarms with both uT and Deluge and capture with wireshark as mentioned above.
Being that I got carried away with the initial wow factor, I have to say Deluge crashes with 2/5 torrents I throw at it... I don't care if it boosts my download from 2 Mbit to 4 Mbit, if I can't USE the thing. I don't see a reason to tout it as anything but a newer client whose only benefit over uT (at the moment) is cross-platform usability through multiple GUI options.

---

FAQ, Guides, Read Me, and Press F1
Zooey | the B.F.E. | Why I forum

Mr Bips

Member

Re: Better encryption

Hello all.. I was just reading this and wondering, could this in any way perhaps be as a result of running Peer Guardian (or similar), as I know that you have/had to allow UTorrent's URL to enable DHT if memory serves at one point....?

Just a thought.

Ultima

Administrator

Re: Better encryption

Hm...? I tend to doubt that connecting to the utorrent.com DHT node would cause the throttling...

---

[size=0.85][ Tweaking Checklist | User Manual | BEE | MiniUI | µTA ][/size]

Greg Hazel

BitTorrent Developer

Re: Better encryption

We observed that running the clients side-by-side had one throttled and one not. So, it can't be any global profiling like watching which hosts are contacted, it has to be something connection-specific.

Switeck

Member

Re: Better encryption

Deluge may never let slip an unencrypted packet...and may somehow obfuscate communication with the tracker?

Greg Hazel

BitTorrent Developer

Re: Better encryption

Deluge may never let slip an unencrypted packet...and may somehow obfuscate communication with the tracker?

Nope, can't be tracker communication, otherwise Deluge would be throttled when uTorrent communicates with the tracker.

Also, it seems Deluge is throttled when encryption is Forced.... (Edit: This was a bug in Deluge - the encryption settings were reversed in the version we used.)