[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

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,
-------------- 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