Capturing packets using ethereal seems to indicate that the seeds/peers that can transfer full speed (aka not throttled) are partially encrypted. If you look at it carefully, only the handshaking is encrypted and not the data transfer. Those connections that attempt to do full encryption seems to be throttled.

If anyone can understand what is going on, then probably can modify windows clients (Azureus since code is available) to work too (that is until TM wisen up). Either that or wait until Deluge windows port is done.

At this point in time, I do not think it's peer id.
As mentioned in my previous posts, I did notice something strange for the IPs that can transfer at high speed.
Half-encrypted (handshake only) instead of full stream encryption.
No idea why that is happening though.

http://www.azureuswiki.com/index.php/Messa...ream_Encryption

BT traffic encryption method (used by all clients supporting encryption) copied from the link above:
1 A->B: Diffie Hellman Ya, PadA
2 B->A: Diffie Hellman Yb, PadB
3 A->B: HASH('req1', S), HASH('req2', SKEY) xor HASH('req3', S), ENCRYPT(VC, crypto_provide, len(PadC), PadC, len(IA)), ENCRYPT(IA)
4 B->A: ENCRYPT(VC, crypto_select, len(padD), padD), ENCRYPT2(Payload Stream)
5 A->B: ENCRYPT2(Payload Stream)

A is the initiator of the connection
B is the receiver
ENCRYPT is RC4 encryption
ENCRYPT2 is encryption method (RC4 or plaintext) choosen by B depending on the options provided by A.

For our case, we assume A is our BT client and B is the peer.
At step 3, A will send the encrypted handshaking with options (crypto_provide) that allow B to select the encryption method.
At step 4, B will send back the choosen encryption method (crypto_select).
At step 4, B will send its handshake packet using the choosen encryption method (plaintext or RC4).
At step 5, further communication will be using the choosen encryption method (plaintext or RC4).

What I am observing (with the limited data I collected) is that peers that can communicate with high speed choose to communicate in plaintext instead of RC4 after the handshaking phase.
This is possible when you set the minimum level of encryption to plaintext as on Deluge.
I have to admit I didn't collect enough data points to further the case though.
I also did not decode the encrypted data in step 3 and step 4 to confirm the data in the handshake packet and crypto_select packet. It's not worth my time writing an app to decode the data.
I am making assumptions that B is choosing plaintext based on the handshake packet that B sent (which is in plaintext and thus readable).
Deluge codes indicates that both RC4 and plaintext bit is set in crypto_provide if the default options are used.


Also, theoretically Azureus should be able to configure minimum level of encryption as well but I am not able to get Azureus to beat the throttle.
Btw, this should be testable by configuring Deluge to Disable legacy connections and also to set minimum level of encryption to RC4 for incoming and outgoing.Unfortunately, I won't be able to test this as I have removed VMware server. Anyone interested to test out?
It didn't occur to me to test this out since I was busy modifying utorrent last time with the peer id theory.