[bittorrent] A few questions regarding extended messages and DHT

Arvid Norberg arvid at cs.umu.se
Tue Nov 20 05:22:39 EST 2007


On Oct 31, 2007, at 09:33, Adrian Ulrich wrote:

> Hi,
>
>> I spoke too soon... The latest uTorrent does just the reverse of  
>> what you
>> wrote above (even though your reasoning is perfectly valid AFAICT).
>
> Interesting. I've just changed my client to send ' m => { ut_pex =>  
> 23 } ' and got some interesting results:
>
> RECV: 1 ;;  <-TR0910-kna91tg5enxv>
> RECV: 23 ;; <-AZ2504-vu> (Always tought that azureus doesn't  
> support ut_pex. Is this a fake client?!)
> RECV: 23 ;; <-KT2210-882503849709>
> RECV: 23 ;; <-UT1750-z>
> RECV: 23 ;; <-UT1610-VBn>
>
>> Should I assume that uTorrent is broken?
>
> Both methods would make 'sense', but we should agree on what method  
> to use :-)
>
> So currently we got two groups of clients:
>
> ______________________________________________________________________ 
> ___
> | Client sends $own-index and    | Client sends $own-index and  
> expects  |
> | expects to receive $own-index  | to receive $peer- 
> index               |
> +-------------------------------- 
> +--------------------------------------+
> | uTorrent 1.6x - 1.7x           | Transmission  
> (libtorrent)            |
> | KTorrent                       |  
> Bitflu                               |
> | Azureus (?)                     
> |                                      |
> +-------------------------------- 
> +--------------------------------------+
>
> I don't know what mainline does (never seen it sending any eproto  
> messages) but as uTorrent holds
> a big 'market-share' libtorrent and bitflu should switch to the  
> 'send own, receive own' method IMO.

libtorrent and uTorrent both do the same thing. Just like the spec says:

"The extension message IDs are the IDs used to send the extension  
messages to the peer sending this handshake"

--
Arvid Norberg





More information about the BitTorrent mailing list