[bittorrent] A few questions regarding extended messages and DHT

ntorrent.20.draza at spamgourmet.com ntorrent.20.draza at spamgourmet.com
Tue Oct 30 14:06:54 EDT 2007


Hi,
 
I have just recently discovered this mailing list - excellent content for BitTorrent implementers.
 
I have a few questions regarding extension messages (as defined by libtorrent and uTorrent) and (for now) one question about (mainline/libtorrent/bitcomet/uTorrent) DHT (so, NOT an Azureus DHT).
 
* It seems that extension protocol is such that two clients that exchange extended handshake (link to the spec http://www.rasterbar.com/products/libtorrent/extension_protocol.html) could opt to map same kind of extended message to the different id, which is slightly confusing to me, but tests with uTorrent show this to be the case. Example: my client initiates the connection, and sends the extended handshake. My client maps "LT_metadata" to 1 and "ut_pex" to 2. uTorrent sends me back just "ut_pex" (expected) but mapped to 1 (?). I can handle this, just wanted to know if this is how it's supposed to work?
* DHT: when generating our own ID, according to the, hm, "spec" (better call it rought sketch of the protocol :)) we should use a lot of entropy to get a random 160-bit value. But the spec does not say if this ID should be really completely random or derived from, I don't know, our IP address and/or MAC address and/or current time or such and should we save this ID accross sessions (restarts of the client). I've observed uTorrent on two machines - on one, it preserves exactly the same ID across sessions, but on the other, the ID changes. What's the deal? How do other authors implement and store this ID?
 
Thanks for any pointers,
 
Drazen
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20071030/685b3623/attachment.html 


More information about the BitTorrent mailing list