You are not logged in.
Pages: 1
This extension allows a peer to join the swarm without having the .torrent file. Someone need merely paste a magnet URL in an email or on a blog. A downloader clicks the link to obtain a list of peers from the DHT and then requests the metainfo file from any of the returned peers.
See http://www.bittorrent.org/beps/bep_0009.html
Please post commentary regarding this method or any related methods deployed in existing BitTorrent implementations.
Offline
The name is confusing. It doesn't describe the extension at all. It doesn't extend the metadata, it provides a way to transfer the metadata on-demand.
Offline
I agree. The name is poor.
Name has been changed to "Extension for Peers to Send Metadata Files."
Offline
There has been almost no commentary about this proposal.
It has been implemented in uTorrent and the editor (me) is inclined to accept it. The "accepted" state is within the power delegated by the BDFL to editors. As it stands, only the BDFL can elevate something to "final" status.
The proposal as it stands has references to LTEP. Thus although accepted this proposal cannot be finalized without also accepting LTEP or its derivative.
Offline
Well, there's only one thing i dislike about it... it's using the 40byte hex representation, whereas all existing links use base32. I've raised the question before... but why change it? I don't see the necessity.
Az dev
Offline
Well, there's only one thing i dislike about it... it's using the 40byte hex representation, whereas all existing links use base32. I've raised the question before... but why change it? I don't see the necessity.
The spec actually says either may be used. My preference would be for a shift to 40byte hex representation, since that is the way the infohash is usually viewed. If supporting clients allow either, there could eventually be a shift.
Offline
The BEP allows both base32 and 40-byte hex.
I don't have much opinion on the matter.
From uTorrent, you can right-click on any torrent and select "copy magnet URI". The generated URI uses the base32 encoding.
Offline
that's my point... it allows 2 encodings where only 1 is necessary and 1 already exists. Apply KISS. If the argument is that users might want to try infohashes directly then this would not require a magnet-prefix. Just enter
a) the raw, hex-encoded infohash [basically just a bonus feature of the client, not part of the standard]
b) the magnet-URI-prefixed base32 infohash [the official way to do it]
-> no confusion, no dead weight
Az dev
Offline
Are there security & privacy issues with this? i.e. could someone snoop on your conversation with a tracker and using the hash they get out of it simply discover exactly what your downloading ?
Last edited by rockinrobstar (2008-07-07 14:18:47)
Offline
they could just google for the infohash too, they're not really considered secret. If you don't want a .torrent retrievable via magnet links you have to mark it as private, otherwise it is considered as a public resource
Az dev
Offline
Greg wants to keep the 40-byte hex. I am booting this up to Bram to consider.
Offline
Am I missing something...
Why doesn't the request message contain the info-hash?
Peers can and often do have metadata for many torrents. How is the peer to know which info-hash it is supposed to send?
Offline
The peers connect to each other normally (as described in BEP3), so the handshake phase still exists.
There is no reason to send the info hash in the request because this information is part of the handshake.
Offline
I propose that the magnet URI format be expanded by an additional parameter to incorporate web seeds, as shown below:
magnet:?xt=urn:btih:<info-hash>&dn=<name>&tr=<tracker-url>&ws=<web-seed>
I also agree that 40 byte hashes should be suppoted, as they are easier to work with.
Offline
the &ws= argument will be supported in uTorrent 2.1
Offline
There is a minor shortcoming in the existing specification. When two peers, without metadata, are connected and then one of them gets the metadata, there is no way for it to advertise to the other peer that it now has it. To overcome this currently the uT implementation polls every 60 seconds by requesting piece 0 of the metadata. This is slightly wasteful.
Instead, when the peer receives metadata, it could send a message to all the BEP9 supporting peers it is aware of, who also do not have the metadata. The message could simply be a new "extension message" (like request, data and reject) which has only two keys:
{'msg_type': 3, 'total_size': 3425}
Polling would still be compatible and allowed, and hopefully old clients which receive msg_type 3 will simply discard it (uT will).
Offline
Technically this seems reasonable, but i question the necessity since the probability of 2 peers not having any metadata connecting to each other is quite low. So they could just ask other peers for it. The only scenario where this could really happen is if many peers start the torrent at the same time, which as of now only happens with RSS feeds - which provide .torrents, not magnets.
Not to mention that many peers starting at once also means that they'll be idle anyway, thus the wasted bandwidth would go unutilized anyway.
So, my question is, does this really provide any practical benefit?
Az dev
Offline
What kind of web-seed does the &ws= extension denote?
The original piece-based web-seed protocol or the 'get-right' HTTP range request based one?
Offline
Pages: 1