peer之间的通信协议

peer之间的通信协议

peer之间的通信协议又称为peer wire protocal，即peer连线协议，它是一个基于TCP协议的应用层协议。

为了防止有的peer只下载不上传，BitTorrent协议建议，客户端只给那些向它提供最快下载速度的4个peer上传数据。简单地说就是谁向我提供下载，我也提供数据供它下载；谁不提供数据给我下载，我的数据也不会上传给它。客户端每隔一定时间，比如10秒，重新计算从各个peer处下载数据的速度，将下载速度最快的4个peer解除阻塞，允许这4个peer从客户端下载数据，同时将其他peer阻塞。

一个例外情况是，为了发现下载速度更快的peer，协议还建议，在任一时刻，客户端保持一个优化非阻塞peer，即无论该peer是否提供数据给客户端下载，客户端都允许该peer从客户端这里下载数据。由于客户端向peer上传数据，peer接着也允许客户端从peer处下载数据，并且下载速度超过4个非阻塞peer中的一个。客户端每隔一定的时间，如30秒，重新选择优化非阻塞peer。

当客户端与peer建立TCP连接后，客户端必须维持的几个状态变量如下表所示。

客户端必须维持的状态变量

状态变量	含义
am_chocking	该值若为1，表明客户端将远程peer阻塞。此时如果peer发送数据请求给客户端，客户端将不会理会。也就是说，一旦将peer阻塞，peer就无法从客户端下载到数据；该值若为0，则刚好相反，即表明peer未被阻塞，允许peer从客户端下载数据
am_interested	该值若为1，表明客户端对远程的peer感兴趣。当peer拥有某个piece，而客户端没有，则客户端对peer感兴趣。该值若为0，则刚好相反，即表明客户端对peer不感兴趣，peer拥有的所有piece，客户端都拥有
peer_chocking	该值若为1，表明peer将客户端阻塞。此时，客户端无法从peer处下载到数据。该值若为0，表明客户端可以向peer发送数据请求，客户端将进行响应
peer_interested	该值若为1，表明peer对客户端感兴趣。也即客户端拥有某个piece，而peer没有。该值若为0，表明peer对客户端不感兴趣

当客户端与peer建立TCP连接后，客户端将这几个变量的值设置为。

am_chocking = 1。

am_interested = 0。

peer_chocking = 1。

peer_interested = 0。

当客户端对peer感兴趣且peer未将客户端阻塞时，客户端可以从peer处下载数据。当peer对客户端感兴趣，且客户端未将peer阻塞时，客户端向peer上传数据。

除非另有说明，所有的整数型在本协议中被编码为4字节值（高位在前低位在后），包括在握手之后所有信息的长度前缀。

客户端与一个peer建立TCP连接后，首先向peer发送握手消息，peer收到握手消息后回应一个握手消息。

l握手消息是一个长度固定为68字节的消息。消息的格式如下：

消息格式中一些参数的含义如下表所示。

握手消息

参数	含义
pstrlen	pstr的长度，该值固定为19
pstr	BitTorrent协议的关键字，即“BitTorrent protocol”
reserved	占8字节，用于扩展BT协议，一般这8字节都设置为0。有些BT软件对BT协议进行了某些扩展，因此可能看到有些peer发来的握手消息这8个字节不全为0，不过不必理会，这不会影响正常的通信
info_hash	与发往Tracker的GET请求中的info_hash为同一个值，长度固定为20字节

peer_id与发往Tracker的GET请求中的peer_id为同一个值，长度固定为20字节。一般从peer_id可以识别出BT软件的类型，例如，某peer发来的握手消息中peer_id的前8个字节为“-AZ2060-”，则可以断定对方使用的是Azureus；若为“-BCxxxx-”，x为数字，则对方使用的是BitComet。

对于除握手消息之外的其他所有消息，其一般的格式为：

length prefix（长度前缀）占4个字节，指明message ID和payload的长度和。message ID（消息编号）占一字节，是一个10进制的整数，指明消息的编号。payload（负载），长度未定，是消息的内容。

lkeep_alive消息：

keep_alive消息的长度固定，为4字节，它没有消息编号和负载。如果一段时间内客户端与peer没有交换任何消息，则与这个peer的连接将被关闭。keep_alive消息用于维持这个连接，通常如果2分钟内没有向peer发送任何消息，则发送一个keep_alive消息。

lchoke消息：

choke消息的长度固定，为5字节，消息长度占4个字节，消息编号占1个字节，没有负载。该消息的功能是，发出该消息的peer将接收该消息的peer阻塞，暂时不允许其下载自己的数据。

lunchoke消息：<id=< span="" style="word-wrap: break-word;">1>

unchoke消息的长度固定，为5字节，消息长度占4个字节，消息编号占1个字节，没有负载。客户端每隔一定的时间，通常为10秒，计算一次各个peer的下载速度，如果某peer被解除阻塞，则发送unchoke消息。如果某个peer原先是解除阻塞的，而此次被阻塞，则发送choke消息。

linterested消息：

interested消息的长度固定，为5字节，消息长度占4个字节，消息编号占1个字节，没有负载。当客户端收到某peer的have消息时，如果发现peer拥有了客户端没有的piece，则发送interested消息告知该peer，客户端对它感兴趣。

lnot interested消息：

not interested消息的长度固定，为5字节，消息长度占4个字节，消息编号占1个字节，没有负载。当客户端下载了某个piece，如果发现客户端拥有了这个piece后，某个peer拥有的所有piece，客户端都拥有，则发送not interested消息给该peer。

lhave消息：

have消息的长度固定，为9字节，消息长度占4个字节，消息编号占1个字节，负载为4个字节。负载为一个整数，指明下标为index的piece，peer已经拥有。每当客户端下载了一个piece，即将该piece的下标作为have消息的负载构造have消息，并把该消息发送给所有与客户端建立连接的peer。

lbitfield消息：

bitfield消息的长度不固定，其中X是bitfield(即位图)的长度。当客户端与peer交换握手消息之后，就交换位图。位图中，每个piece占一位，若该位的值为1，则表明已经拥有该piece；为0则表明该piece尚未下载。具体而言，假定某共享文件共拥有801个piece，则位图为101个字节，位图的第一个字节的最高位指明第一个piece是否拥有，位图的第一个字节的第二高位指明第二个piece是否拥有，依此类推。对于第801个piece，需要单独一个字节，该字节的最高位指明第801个piece是否已被下载，其余的7位放弃不予使用。

lrequest消息：

request消息的长度固定，为17个字节，index是piece的索引，begin是piece内的偏移，length是请求peer发送的数据的长度。当客户端收到某个peer发来的unchoke消息后，即构造request消息，向该peer发送数据请求。前面提到，peer之间交换数据是以slice（长度为16KB的块）为单位的，因此request消息中length的值一般为16K。对于一个256KB的piece，客户端分16次下载，每次下载一个16K的slice。

lpiece消息：

piece消息是另外一个长度不固定的消息，长度前缀中的9是id、index、begin的长度总和，index和begin固定为4字节，X为block的长度，一般为16K。因此对于piece消息，长度前缀加上id通常为00 00 40 09 07。当客户端收到某个peer的request消息后，如果判定当前未将该peer阻塞，且peer请求的slice，客户端已经下载，则发送piece消息将文件数据上传给该peer。

lcancel消息：<id<=8 style="word-wrap: break-word;">

cancel消息的长度固定，为17个字节，len、index、begin、length都占4字节。它与request消息对应，作用刚好相反，用于取消对某个slice的数据请求。如果客户端发现，某个piece中的slice，客户端已经下载，而客户端又向其他peer发送了对该slice的请求，则向该peer发送cancel消息，以取消对该slice的请求。事实上，如果算法设计合理，基本不用发送cancel消息，只在某些特殊的情况下才需要发送cancel消息。

lport消息：

port消息的长度固定，为7字节，其中listen-port占两个字节。该消息只在支持DHT的客户端中才会使用，用于指明DHT监听的端口号，一般不必理会，收到该消息时，直接丢弃即可。

peer之间的通信协议相关推荐

禄来6008机身和镜头之间的通信协议测试
帮色友测试禄来6008机身和镜头之间的通信协议. 此机身接口上有10个触点,从右到左分别编号为1至10. 测到第4个触点的电压在开机状态下是5 V,按下景深预览的时候没有特别波形,在弹起景深预览按钮时 ...
如何去设计硬件与程序之间的通信协议
硬件跟程序之间通信就是传递的byte数组,所以需要定义规则进行解析,这里的规则指的就是协议. 协议是由硬件工程师跟软件开发一起制定的农业项目通信格式(沙盘专用),沙盘采购的传感器跟后续使用的传感器不 ...
自己设计系统之间的通信协议
一个突发奇想昨天一直在想http协议的问题,http协议是基于TCP/IP协议的,我一直在想,http的实体在哪里?后来我想,http不过是一个"全球范围内的承诺",所有使用 ...
浏览器，服务器，浏览器和服务器之间的通信协议
1,world wide web 我们通常所说的web就是指world wide web.一般来讲,这一种通过浏览器来访问资源的技术.我们经常说的上网,应该大部都是指的是上万维网(web),但是我们经 ...
GBT 27930-2015电动汽车非车载传导式充电机与电池管理系统之间的通信协议(mgq)
使用GD32F30X系列编写适用于GBT 27930-2015的充电协议适用的代码,具体代码如下: uint8_t gBCP_message[13]={0,0,0,0,0,0,0,0,0,0,0,0, ...
基于TCP/UDP的P2P网络通信协议研究与实现
此章节是理论知识,下个章节会奉献源码摘要对等式网络(peer-to-peer,简称P2P),又称点对点技术,是一种实现网络中不同主机直接通信的技术.在物联网的应用中,大量的设备需要能进行点 ...
java解析bt协议详解_BT（带中心Tracker）通信协议的分析
BT通信协议举例分析现在的很多BT下载都采用了DHT网络,这样进行BT下载就不需要中心服务器了.本文针对的是需要中心服务器的BT下载. 小弟我最近正在研究BT通信协议,网上的资料很全,但是不是那事详 ...
微服务之间单点登录和用户权限认证的实现
目录单系统登录机制 HTTP无状态协议 Cookie会话机制登录状态多系统登录难点单点登录系统单点登录流程单点注销流程部署图子系统与sso认证中心的功能准备工作项目结构修改网关配 ...
全网首发！老大众奥迪碟盒通信协议破解，可以模拟数码碟盒，外接AUX蓝牙U盘等音频设备
文章目录前言什么是碟盒? 碟盒接口定义车机与碟盒之间的通信协议主机向碟盒发送数据协议数据帧格式逻辑分析仪真机抓包分析起始信号波形: 数据0信号波形: 数据1信号波形: 逻辑分析仪抓包分析 ...
FPGA与单片机之间的数据通信
目录一.FPGA简介二.FPGA与单片机之间的通信协议制定 1.通信系统框图 2.通信时序图三.实例总结一.FPGA简介写了这么久的Verilog代码,还没有系统的总结 ...

peer之间的通信协议

peer之间的通信协议相关推荐

最新文章

热门文章