本文转自：https://blog.csdn.net/xxxxxx91116/article/details/8549454
本文仅作为应急备份存储，如有侵权可发送邮件删除。
Extension for Peers to Send Metadata Files
这个扩展的目的是为了在最初没有.torrent文件的情况仍然能够加入swarm并能够完成下载。这个扩展能让客户端从peer哪里下载metadata。这让支持magnet link成为了可能，magnet link是一个web页上的链接，仅仅包含了足够加入swarm的足够信息(info hash)。
Metadata
这个扩展仅仅传输.torrent文件的info-字典字段，这个部分可以由infohash来验证。在这篇文档中，.torrent的这个部分被称为metadata。
Metadata被分块，每个块有16KB(16384字节)，Metadata块从0开始索引，所有快的大小都是16KB，除了最后一个块可能比16KB小。
Extension头部
Metadata扩展使用extension协议(详见BEP0010)来声称它的存在。它在extension握手消息的头部m字典加入ut_metadata项。这个标识这个消息可以使用这个消息码，同时也可以在握手消息中加入metadata_size这个整型字段(不是在m字典中)来指定metadata的字节数。
Extension握手消息的例子：
{'m': {'ut_metadata', 3}, 'metadata_size': 31235}
Example extension handshake message:
{'m': {'ut_metadata', 3}, 'metadata_size': 31235}
Extension消息
Extension消息都是bencode编码，这里有3类不同的消息：
0.request
1.data
2.reject
bencode消息有一个整型关键字字段msg_type，与其消息类型对应，同时还有一个关键字段piece来表示这个消息说的是metadata的哪个块。
为了将来协议的扩展，未识别的消息ID要忽略掉。
Request
请求
请求消息并不在字典中附加任何关键字，这个消息的回复应当来自支持这个扩展的peer，是一个reject或者data消息，回复必须和请求所指出的片相同。
Peer必须保证它所发送的每个片都通过了infohash的检测。即直到peer获得了整个metadata并通过了infohash的验证，才能够发送片。Peers没有获得整个metadata时，对收到的所有metadata请求都必须直接回复reject消息。
例子：
{'msg_type': 0, 'piece': 0}
d8:msg_typei0e5:piecei0ee
这代表请求消息在请求metadata的第一片。
Data
这个data消息需要在字典中添加一个新的字段，"total_size".这个关键字段和extension头的"metadata_size"有相同的含义，这是一个整型。
Metadata片被添加到bencode字典后面，他不是字典的一部分，但是是消息的一部分(必须包括长度前缀)。
如果这个片是metadata的最后一个片，他可能小于16KB。如果它不是metadata的最后一片，那大小必须是16KB。
例子：
{'msg_type': 1, 'piece': 0, 'total_size': 3425}
d8:msg_typei1e5:piecei0e10:total_sizei34256eexxxxxxxx...
x表示二进制数据(metadata)。
Reject
Reject消息没有附件的关键字。它的意思是peer没有请求的这个metadata片信息。
在客户端收到收到一定数目的消息后，可以通过拒绝请求消息来进行洪泛攻击保护。尤其在metadata的数目乘上一个因子时。
例子：
{'msg_type': 2, 'piece': 0}
d8:msg_typei1e5:piecei0ee
Magnet URI格式
magnet:?xt=urn:btih:<info-hash>&dn=<name>&tr=<tracker-url>
<info-hash>
Infohash的16进制编码，共40字符。为了与其它的编码兼容，客户端应当也支持32字符的infohash base32编码。
Xt是唯一强制的参数;dn是在等待metadata时可能供客户端显示的名字。如果只有一个字段，Tr是tracker的url，如果有很多的tracker，那么多个tr字段会被包含进去。
dn和tr都是可选的。
如果没有指定tracker，客户端应使用DHT【BEP0005】来获取peers