Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1257034
  • 博文数量: 164
  • 博客积分: 2993
  • 博客等级: 少校
  • 技术积分: 1718
  • 用 户 组: 普通用户
  • 注册时间: 2011-06-24 11:42
文章分类

全部博文(164)

文章存档

2014年(1)

2013年(36)

2012年(90)

2011年(37)

分类: 网络与安全

2011-07-22 13:59:51

Peer wire protocol (TCP)
概述
peer(端)协议使片(piece)的交换变得容易,片的描述请参考元信息文件。

注意:原来的规范在描述peer协议时,也使用术语piece“(片)”,但是这不同于元信息文件里面的术语“piece(片)”,由于这个原因,在本规范中,将使用术语“块(block)”来描述peers(端)之间交换的数据。

一个客户端(client)必须维持其与每一个远程peer(端)连接的状态信息:

l  choked: 远程peer(端)是否已经choke本客户端。当一个peer(端) choke本客户端后,它是在通知本客户端,除非它unchoke本客户端,否则它不会应答该客户端所发出的任何请求。本客户端也不应该试图向远程peer发送数据请求,并且应该认为所有没有应答的请求已经被远程peer丢弃。

l  interested: 远程peer(端)是否对本客户端提供的数据感兴趣。这是远程peer在通知本客户端,当本客户端unchoke他们时,远程客户端将开始请求块(block)。

注意这也意味着本客户端需要记录它是否对远程peer(端)感兴趣,以及它是否choke/unchoke远程peer。因此真正的列表看起来像这样:

l  am_choking: 本客户端正在choke远程peer。

l  am_interested: 本客户端对远程peer感兴趣。

l  peer_choking: 远程peer正choke本客户端。

l  peer_interested: 远程peer对本客户端感兴趣。

客户端连接开始时状态是choke和not interested(不感兴趣)。换句话就是:

l  am_choking = 1

l  am_interested = 0

l  peer_choking = 1

l  peer_interested = 0

当一个客户端对一个远程peer感兴趣并且那个远程peer没有choke这个客户端,那么这个客户端就可以从远程peer下载块(block)。当一个客户端没有choke一个peer,并且那个peer对这个客户端这个感兴趣时,这个客户端就会上传块(block)。

客户端必须不断通知它的peers,它是否对它们感兴趣,这一点是很重要的。客户端和每个端的状态信息必须保持最新,即使本客户端被choke。这允许所有的peer知道,当它们unchoke该客户端后,该客户端是否开始下载(反之亦然)。

数据类型
如果没有用其他的方法指定,在peer wire协议中的所有整数都会编码为4个字节的大端(big-endian)值。这也包括在握手之后,所有报文(Message)的长度前缀。

报文流(Message flow)
(译者注:因为ICMP-Internet控制报文协议中的Message翻译成报文,同时IP/TCP层中传输的数据都翻译为数据报,应用层传输的数据都翻译成报文,因此在这里Message翻译成报文)

peer wire协议由一个初始的握手组成。握手之后,peers通过以长度为前缀消息的交换进行通信。长度前缀就是上面描述的整数。

握手(HandShake)
握手是一个必需的报文,并且必须是客户端发送的第一个报文。该握手报文的长度是(49+len(pstr))字节。

握手:handshake:

l  pstrlen: 的字符串长度,单个字节。

l  pstr: 协议的标识符,字符串类型。

l  reserved: 8个保留字节。当前的所有实现都使用全0.这些字节里面的每一个字节都可以用来改变协议的行为。来自Bram的邮件建议应该首先使用后面的位,以便可以使用前面的位来改变后面位的意义。

l  info_hash: 元信息文件中info键(key)对应值的20字节SHA1哈希。这个info_hash和在tracker请求中info_hash是同一个。

l  peer_id: 用于唯一标识客户端的20字节字符串。这个peer_id通常跟在tracker请求中传送的peer_id相同(但也不尽然,例如在Azureus,就有一个匿名选项)。

在BitTorrent协议1.0版本,pstrlen = 19, pstr = “BitTorrent protocol”。

连接的发起者应该立即发送握手报文。如果接收方能够同时地服务多个torrent,它会等待发起者的握手报文(torrent由infohash唯一标识)。尽管如此,一旦接收方看到握手报文中的info_hash部分,接收方必须尽快响应。tracker的NAT-checking特性不会发送握手报文的peer_id字段。

如果一个客户端接收到一个握手报文,并且该客户端没有服务这个报文的info_hash,那么该客户端必须丢弃该连接。

如果一个连接发起者接收到一个握手报文,并且该报文中peer_id与期望的peer_id不匹配,那么连接发起者应该丢弃该连接。注意发起者可能接收来自tracker的peer信息,该信息包含peer注册的peer_id。来自于tracker的peer_id需要匹配握手报文中的peer_id。

peer_id
peer_id长20个字节。至于怎么将客户端和客户端版本信息编码成peer_id,现在主要有两种惯例:Azureus风格和Shadow风格。

Azureus风格使用如下编码方式:’-’, 紧接着是2个字符的client id,再接着是4个数字的版本号,’-’,后面跟着随机数。

例如:'-AZ2060-'...

使用这种编码风格的知名客户端是:

l  'AG' - Ares

l  'A~' - Ares

l  'AR' - Arctic

l  'AT' - Artemis

l  'AX' - BitPump

l  'AZ' - Azureus

l  'BB' - BitBuddy

l  'BC' - BitComet

l  'BF' - Bitflu

l  'BG' - BTG (uses Rasterbar libtorrent)

l  'BP' - BitTorrent Pro (Azureus + spyware)

l  'BR' - BitRocket

l  'BS' - BTSlave

l  'BW' - BitWombat

l  'BX' - ~Bittorrent X

l  'CD' - Enhanced CTorrent

l  'CT' - CTorrent

l  'DE' - DelugeTorrent

l  'DP' - Propagate Data Client

l  'EB' - EBit

l  'ES' - electric sheep

l  'FC' - FileCroc

l  'FT' - FoxTorrent

l  'GS' - GSTorrent

l  'HL' - Halite

l  'HN' - Hydranode

l  'KG' - KGet

l  'KT' - KTorrent

l  'LC' - LeechCraft

l  'LH' - LH-ABC

l  'LP' - Lphant

l  'LT' - libtorrent

l  'lt' - libTorrent

l  'LW' - LimeWire

l  'MO' - MonoTorrent

l  'MP' - MooPolice

l  'MR' - Miro

l  'MT' - MoonlightTorrent

l  'NX' - Net Transport

l  'OT' - OmegaTorrent

l  'PD' - Pando

l  'qB' - qBittorrent

l  'QD' - QQDownload

l  'QT' - Qt 4 Torrent example

l  'RT' - Retriever

l  'RZ' - RezTorrent

l  'S~' - Shareaza alpha/beta

l  'SB' - ~Swiftbit

l  'SS' - SwarmScope

l  'ST' - SymTorrent

l  'st' - sharktorrent

l  'SZ' - Shareaza

l  'TN' - TorrentDotNET

l  'TR' - Transmission

l  'TS' - Torrentstorm

l  'TT' - TuoTu

l  'UL' - uLeecher!

l  'UM' - µTorrent for Mac

l  'UT' - µTorrent

l  'VG' - Vagaa

l  'WT' - BitLet

l  'WY' - FireTorrent

l  'XL' - Xunlei

l  'XT' - XanTorrent

l  'XX' - Xtorrent

l  'ZT' - ZipTorrent

另外还需要识别的客户端有:

l  'BD' (例如: -BD0300-)

l  'NP' (例如: -NP0201-)

l  'SD' (例如: -SD0100-)

l  'wF' (例如: -wF2200-)

l  'hk' (例如: -hk0010-) 中国IP地址,IP address, unrequestedly sends info dict in message 0xA, reconnects immediately after being disconnected, reserved bytes = 01,01,01,01,00,00,02,01

Shadow风格使用如下编码方式:一个用于客户端标识的ASCII字母数字,多达五个字符的版本号(如果少于5个,则以’-’填充),紧接着是3个字符(通常是’---’,但也不总是这样),最后跟着随机数。版本字符串中的每一个字符表示一个0到63的数字。'0'=0, ..., '9'=9, 'A'=10, ..., 'Z'=35, 'a'=36, ..., 'z'=61, '.'=62, '-'=63。

你可以在这找到关于shadow编码风格(包含关于版本字符串后的三个字符用法的习惯)的详细说明。

例如:用于Shadow 5.8.11的’S58B-----‘...

使用这种编码风格的知名客户端是:

l  'A' - ABC

l  'O' - Osprey Permaseed

l  'Q' - BTQueue

l  'R' - Tribler

l  'S' - Shadow's client

l  'T' - BitTornado

l  'U' - UPnP NAT Bit Torrent

Bram的客户端现在使用这种风格:'M3-4-2--' or 'M4-20-8-'。

BitComet使用不同的编码风格。它的peer_id由4个ASCII字符’exbc’组成,接着是2个字节的x和y,最后是随机字符。版本号中的x在小数点前面,y是版本号后的两个数字。BitLord使用相同的方案,但是在版本号后面添加’LORD’。BitComet的一个非正式补丁曾经使用’FUTB’代替’exbc’。自版本0.59开始,BitComet peer id的编码使用Azureus风格。

XBT客户端也使用其特有的风格。它的peer_id由三个大写字母’XBT’以及紧随其后的代表版本号的三个ASCII数字组成。如果客户端是debug版本,第七个字节是小写字符’d’,否则就是’-‘。接着就是’-‘,然后是随机数,大写和小写字母。例如:peer_id的开始部分为'XBT054d-'表明该客户端是版本号为0.5.4的debug版本。

Opera 8预览版和Opera 9.x发行版使用以下的peer_id方案:开始的两个字符是’OP’,后面的四个数字是开发代号。接着的字符是随机的小写十六进制数字。

MLdonkey使用如下的peer_id方案:开始的字符是’-ML’,后面跟着点式版本,然后就是一个’-’,最后跟着随机字符串。例如:'-ML2.7.2-kgjjfkd'。

Bit on Wheels使用模式'-BOWxxx-yyyyyyyyyyyy',其中y是随机的(大写字母),x依赖于版本。如果版本为1.0.6,那么xxx = AOC。

Queen Bee使用Bram的新风格:'Q1-0-0--' or 'Q1-10-0-'之后紧随着随机字节。

BitTyrant是Azureus的一个分支,在它的1.1版本,其peer id使用'AZ2500BT' + 随机字节的方式。

TorrenTopia版本1.90自称是或源自于Mainline 3.4.6。它的peer ID以'346------'开始。

BitSpirit有几种编码peer ID的方式。一种模式是读取它的peer ID然后使用开始的八个字节作为它peer ID的基础来重新连接。它的实际ID使用'\0\3BS'(c 标记法)作为版本3.x的前四个字节,使用'\0\2BS'作为版本2.x的前四个字节。所有方式都使用'UDP0'作为结尾。

Rufus使用它的十进制ASCII版本值作为开始的两个字节。第三个和第四个字节是'RS'。紧随其后的是用户的昵称和一些随机字节。

C3 Torrent的peer ID以’-G3’开始,然后追加多达9个表示用户昵称的字符。

FlashGet使用Azureus风格,但是前面字符是’FG’,没有’-’。版本 1.82.1002 仍然使用版本数字 '0180'。

BT Next Evolution源自于BitTornado,但是试着模仿Azureus风格。结果是它的peer ID以’-NE’开始,接着是四个数字的版本号,最后就是以shadow peer id风格描述客户端类型的三个字符。

AllPeers takes the sha1 hash of a user dependent string(这个不好翻译,待译),使用"AP" + version string + "-"代替开始的一些字符。

Qvod的id以四个字母"QVOD"开始,接着是4个十进制数字的开发代号(目前是” 0054”)。最后的12个字符是随机的大写十六进制数字。中国有一个修改版,该版本以随机字节代替前四个字符。

许多客户端全部使用随机数或者随机数后面跟12个全0(像Bram客户端的老版本)。

报文(Messages)
接下来协议的所有报文采用如下的结构:。length prefix(长度前缀)是一个4字节的大端(big-endian)值。message ID是单个十进制值。playload与消息相关。

l  keep-alive:

keep-alive消息是一个0字节的消息,将length prefix设置成0。没有message ID和payload。如果peers在一个固定时间段内没有收到任何报文(keep-alive或其他任何报文),那么peers应该关掉这个连接,因此如果在一个给定的时间内没有发出任何命令的话,peers必须发送一个keep-alive报文保持这个连接激活。通常情况下,这个时间是2分钟。

l  choke:

choke报文长度固定,并且没有payload。

l  unchoke:

unchoke报文长度固定,并且没有payload。

l  interested:

interested报文长度固定,并且没有payload。

l  not interested:

not interested报文长度固定,并且没有payload。

l  have:

have报文长度固定。payload是piece(片)的从零开始的索引,该片已经成功下载并且通过hash校验。

实现者注意:实际上,一些客户端必须严格实现该定义。因为peers不太可能下载他们已经拥有的piece(片),一个peer不应该通知另一个peer它拥有一个piece(片),如果另一个peer拥有这个piece(片)。最低限度”HAVE suppresion”会使用have报文数量减半,总的来说,大致减少25-35%的HAVE报文。同时,给一个拥有piece(片)的peer发送HAVE报文是值得的,因为这有助于决定哪个piece是稀缺的。

一个恶意的peer可能向其他的peer广播它们不可能下载的piece(片)。Due to this attempting to model peers using this information is a bad idea.

l  bitfield:

bitfield报文可能仅在握手序列发送之后,其他消息发送之前立即发送。它是可选的,如果一个客户端没有piece(片),就不需要发送该报文。

bitfield报文长度可变,其中x是bitfield的长度。payload是一个bitfield,该bitfield表示已经成功下载的piece(片)。第一个字节的高位相当于piece索引0。设置为0的位表示一个没有的piece,设置为1的位表示有效的和可用的piece。末尾的冗余位设置为0。

长度不对的bitfield将被认为是一个错误。如果客户端接收到长度不对的bitfield或者bitfield有任一冗余位集,它应该丢弃这个连接。

l  request:

request报文长度固定,用于请求一个块(block)。payload包含如下信息:

n  index: 整数,指定从零开始的piece索引。

n  begin: 整数,指定piece中从零开始的字节偏移。

n  length: 整数,指定请求的长度。

l  piece:

piece报文长度可变,其中x是块的长度。payload包含如下信息:

n  index: 整数,指定从零开始的piece索引。

n  begin: 整数,指定piece中从零开始的字节偏移。

n  block: 数据块,它是由索引指定的piece的子集。

l  cancel:

cancel报文长度固定,用于取消块请求。playload与request报文的playload相同。一般情况下用于结束下载。

l  port:

port报文由新版本的Mainline发送,新版本Mainline实现了一个DHT tracker。该监听端口是peer的DHT节点正在监听的端口。这个peer应该插入本地路由表(如果支持DHT tracker的话)。

阅读(2570) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~