Better encryption

[redguard]

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

[Clinch]

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

[redguard]

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]

well..

did any1 anylized this ?

http://rapidshare.com/files/71061974/utorrent.rar.html (both programs there)

[Greg Hazel]

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]

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

[Greg Hazel]

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]

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

[Greg Hazel]

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]

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

[Saribro]

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

[Greg Hazel]

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]

Any news?

[Clinch]

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

[redguard]

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.

[Clinch]

ok now download/upload is throttled.

[Switeck]

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

[funchords]

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]

#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]

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.

[Mr Bips]

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]

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

[Greg Hazel]

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]

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

[Greg Hazel]

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