DHT协议发送metadata文件扩展
翻译自：Extension for Peers to Send Metadata Files
DHT协议扩展：发送metadata文件
此扩展的目的是允许客户端加入swarm并完成下载，而无需先下载.torrent文件。相反，此扩展允许客户端从对等方下载元数据。它使得支持磁力链接成为可能，一个网页上的链接只包含足够的信息来加入swarm（info hash）。
metadata
此扩展名仅传输.torrent文件的信息字典部分。此部分可以通过info-hash进行验证。在本文档中，.torrent文件的这部分称为元数据（metadata）。
元数据以16KiB（16384字节）的块进行处理。元数据块的索引从0开始。除最后一个可能是更小的区块外，所有区块均为16KiB。
扩展头
元数据扩展使用扩展协议（在BEP 0010中指定）公布其存在。它将“ut_metadata”条目添加到扩展头握手消息中的“m”字典中。这标识了用于此消息的消息代码。它还向握手消息（而不是“m”字典）添加“metadata_size”，指定元数据字节数的整数值。
扩展握手消息示例：
1 | |
扩展信息
扩展消息是结果B编码的。有3种不同类型的消息：
- request
- data
- reject
b编码消息有一个键“msg_type”，该值是与消息类型对应的整数。它们还有一个关键的“piece”，指示此消息所指的元数据的哪一部分。
为了支持将来的可扩展性，必须忽略无法识别的消息ID。
request
request消息在字典中没有任何其他键。来自支持扩展的对等方对此消息的响应是reject或data信息。响应必须与请求具有相同的piece。
peer必须验证它发送的任何piece都通过了info-hash验证。比如，在对等方拥有整个元数据之前，它无法运行SHA-1来验证它是否生成与信息哈希相同的哈希。没有完整元数据的对等方必须以reject消息响应任何元数据请求。
例子：
1 | |
该请求消息请求第一个元数据块。
data
data消息向字典中添加了另一个条目“total_size”。该键与扩展头中的“metadata_size”具有相同的语义。这是一个整数。
元数据片段被附加到b编码字典中，它不是字典的一部分，而是消息的一部分（长度前缀必须包含它）。
如果该块是元数据的最后一块，则它可能小于16kiB。如果它不是元数据的最后一块，那么它必须是16kiB。
例子：
1 | |
x表示二进制数据（元数据）。
reject
reject消息的消息中没有任何其他键。应该将其解释为对等方没有请求的元数据。
客户端可以通过在服务了一定数量的request消息之后拒绝它们来实现洪水防护。通常是元数据条数乘以一个因子。
例子：
1 | |
磁力链接格式
磁力链接格式为：
1 | |
是info-hash十六进制编码，总共40个字符。为了与现有链接兼容，客户端还应该支持32个字符的base32编码信息散列。
是新元数据格式的torrents的多哈希格式、十六进制编码的完整infohash。“btmh”和“btih”确切主题可能存在于同一磁力中，如果它们描述相同的混合torrent。
peer地址表示为hostname:port,ipv4-literal:port或者[ipv6-literal]:port。可以包含此参数以启动两个客户端之间的直接元数据传输，同时减少对外部对等源的需求。只有当客户端能够发现其公共IP地址并确定其可访问性时，才应包括该地址。注意：由于没有为bittorrent分配URI方案标识符，因此xs=不用于此目的。
xt是唯一必需的参数。dn是客户端在等待元数据时可用于显示的显示名称。tr是一个跟踪器url（如果有）。如果有多个跟踪器，则可能包括多个tr条目。这同样适用于x.pe条目。
dn、tr和x.pe都是可选的。
如果未指定跟踪器，则客户端应使用DHT（BEP 0005）获取peer。
