P2P应用

发布时间:2023年12月22日

目录

一.P2P的简介

二.P2P的工作方式

1.具有集中目录服务器的P2P工作方式

2.具有全分布式结构的P2P文件共享程序


一.P2P的简介

P2P(对等连接),是指两台主机在通信时,并不区分哪一个是服务请求方和哪一个是服务提供方。只要两台主机都运行了对等连接软件(P2P 软件),它们就可以进行平等的对等连接通信。这时,双方都可以下载对方已经存储在硬盘中的共享文档。

如图,主机C,D,E和F都运行了P2P程序,因此这几台主机都可进行对等通信(如 C和D,E和F,以及C和F)。实际上,对等连接方式从本质上看仍然使用客户-服务器方式,只是对等连接中的每一台主机既是客户同时又是服务器。例如主机C,当C请求D的服务时,C 是客户,D 是服务器。但如果C 又同时向F提供服务,那么C又同时起着服务器的作用。

二.P2P的工作方式

1.具有集中目录服务器的P2P工作方式

最早使用P2P工作方式的是Napster。Napster 能够搜索音乐文件,能够提供检索功能。所有音乐文件的索引信息都集中存放在Napster 目录服务器中。这个目录服务器起着索引的作用。使用者只要查找目录服务器,就可知道应从何处下载所要的 MP3文件。

这里的关键就是运行 Napster 的所有用户,都必须及时向 Napster 的目录服务器报告自己已经存有哪些音乐文件。Napster 目录服务器就用这些用户信息建立起一个动态数据库,集中存储了所有用户的音乐文件信息(即对象名和相应的 IP 地址)。当某个用户想下载某个MP3 文件时,就向目录服务器发出查询(这个过程仍是传统的客户-服务器方式),目录服务器检索出结果后向用户返回存放这一文件的计算机 IP 地址,于是这个用户就可以从中选取一个地址下载想要得到的 MP3 文件(这个下载过程就是 P2P 方式)。可以看出,Napster的文件传输是分散的(P2P 方式),但文件的定位则是集中的(客户-服务器方式)。

其工作方式如下图所示:

① 用户X向Napster 目录服务器查询(客户-服务器方式)谁有文件MP3#。

② Napster 目录服务器回答X:有三个地点有文件MP3#,即A,B和C(给出了这三个地点的IP 地址)。于是用户X 得知所需的文件 MP3#的三个下载地点。

③ 用户X可以随机地选择三个地点中的任一个,也可以使用 PING 报文寻找最方便下载的一个。在图中,我们假定X向A发送下载文件 MP3#的请求报文。现在X和A都使用 P2P方式通信,互相成为对等方,X 是临时的客户,而对等方A是临时的服务器。

④ 对等方A(现在作为服务器)把文件MP3#发送给X。
这种集中式目录服务器的最大缺点就是可靠性差,而且会成为其性能的瓶颈(尤其是在用户数非常多的情况下)。

2.具有全分布式结构的P2P文件共享程序

Gnutella是P2P文件共享程序的代表,他是一种采用全分布方法定位内容的P2P文件共享应用程序。Gnutella与Napster 最大的区别就是不使用集中式的目录服务器进行查询,而是使用洪泛济在大量Gnutella 用户之间进行查询。为了不使查询的通信量过大,Gnutella 设计了一种有限范围的洪泛查询。这样可以减少倾注到互联网的查询流量,但由于查询的范围受限,因而这也影响到查询定位的准确性。

现在比较好的查找方法是设法构建一种分布式数据库,以进行对等方及其资源的定位。这种分布式数据库在概念上并不复杂,只要能够支持大量对等方(可能有几百万个)进行索引查找即可。存储在数据库中的信息只有两个部分:
(1)要查找的资源名K(例如,电影或歌曲的名字)。资源名也可称为关键字

(2)存放该对象的节点的IP地址N。有的 IP 地址还附带有端口号。

存放在数据库中的信息就是大量成对出现的(资源名 K,节点的 IP 地址N)。在查找某资源名 K 时,只要在数据库中查找到匹配的资源名 K,数据库就能够返回对应的节点的 IP地址N。所以问题的关键就是要设法把每个资源名 K 存放在一个非常便于查找的地方。现在广泛使用的索引和查找技术叫作分布式散列表DHT(Distributed Hash Table)。基于DHT的具体算法中,广泛使用的是Chord算法。

分布式散列表 DHT 利用散列函数,把资源名K及其存放的节点 IP 地址都分别映为资源名标识符KID和节点标识符 NID。

(1)节点标识符NID按照其标识符值映射到Chord 环上对应的点,就是图中标有NID的小圆点,如N4,N7,N10,N20,N26和N30。
(2)资源名标识符 KID则按照其标识符值映射到与其值最接近的下一个 NID,见图,标有KID的小方块。所谓“最接近的下一个”NID就是指:从 KID 值开始,按顺时针方向沿Chord环遇到的下一个NID。例如,K31和K2应放在N4,因为在环上从31和2按顺时针方向遇到的下一个NID是N4。同理,K8,K12,K23和K29应分别放在N10,N20,N26和N30。如果碰巧同时出现K29和N29(这种概率极小),那么K29就应当放在N29。

注:在图中,K31和K2都放在N4,这表示要查找存放资源 K31或K2的节点的 IP 地址,就应当到节点 N4 去查找。但是,资源 K31和 K2并非存放在节点N4。

每个资源由 Chord 环上与其标识符值最接近的下一个节点提供服务。Chord 环并非实际的网络。在 Chord 环上相邻的节点,在地理上很可能相距非常远。

chord算法原理较复杂,具体可以看:

http://t.csdnimg.cn/28EKD

为了更加有效地在大量用户之间使用 P2P 技术下载共享文件,最近几年已经开发出很多种第三代P2P共享文件程序[KURO17],它们使用分散定位和分散传输技术。如KaZaA,电骡eMule,比特洪流BT(Bit Torrent)等。

BT洪流有两个关键的部分组成:文件块(chunk)和追踪器(tracker)

文件块:BT把对等方下载文件的数据单元称为文件块chunk),一个文件块的长度是固定不变的,例如,典型的数值是 256 KB。当一个新的对等方加入某个洪流时,一开始它并没有文件块。但新的对等方逐渐地能够下载到一些文件块。而与此同时,它也为别的对等方上传一些文件块。某个对等方获得了整个的文件后,可以立即退出这个洪流(相当于自私的用户),也可继续留在这个洪流中,为其他的对等方上传文件块(相当于无私的用户)。加入或退出某个洪流可在任何时间完成(即使在某个文件还没有下载完毕时),也是完全自由的。

追踪器:每一个洪流都有一个基础设施节点,叫作追踪器(tracker)。当一个对等方加入洪流时,必须向追踪器登记(或称为注册),并周期性地通知追踪器它仍在洪流中。追踪器因而就跟踪了洪流中的对等方。一个洪流中可以拥有少到几个多到几百或几千个对等方。

BT洪流的工作原理:

① 当一个新的对等方A?加入洪流时,追踪器就随机地从参与的对等方集合中选择若干个(例如,30个),并把这些对等方的 IP 地址告诉A。于是A就和这些对等方建立了TCP连接。我们称所有与A建立了TCP连接的等方为“相邻对等方”(neighboring peers)。在图中我们在上面的覆盖网络中画出了有三个相邻对等方(B,C和 D)。这些相邻对等方的数目是动态变化的,有的对等方可能不久就离开了,但不久后又有新加入进来的对等方。
② 在任何时刻,每一个对等方可能只拥有某文件的一个文件块子集,而不同的对等方所拥有的文件块子集也不会完全相同。对等方 A 将通过TCP连接周期性地向其相邻对等方索取它们拥有的文件块列表。根据收到的文件块列表,A 就知道了应当请求哪一个相邻对等方把哪些自己缺少的文件块发送过来。

上图是对等方之间互相传送数据块的示意图。例如,A向 B、C和D 索取数据块,但B同时也向 C和 D传送数据块,D和C 还相传送数据块。由于 P2P 对等用户的数量非常多,因此,从不同的对等方获得不同的数据块,然后组装成整个的文件,一般要比仅从一个地方下载整个的文件要快很多。

然而 A 必须做出两个重要决定。第一,哪些文件块是首先需要向其相邻对等方请求的?第二,在很多向A 请求文件块的相邻对等方中,A 应当向哪些相邻对等方发送所请求的文件块?
对于第一个问题,A要使用叫作最稀有的优先(rarest first)的技术。我们知道,凡是A所缺少的而正好相邻对等方已拥有的文件块,都应当去索取。可能其中的某些文件块,很多相邻对等方都有(即文件块的副本很多),这就是“不稀有的”文件块,以后可慢慢请求。如果 A 所缺少的文件块在相邻对等方中的副本很少,那就是“很稀有的”。因此,A 首先应当请求副本最少的文件块(即最稀有的)。否则,一旦拥有最稀有文件块的对等方退出了洪流,就会影响A对所缺文件块的收集。

对于第二个问题,BT采用了一种更加机灵的算法,其基本思想就是:凡当前有以最高数据率向A传送文件块的某相邻对等方,A 就优先把所请求的文件块传送给该相邻对等方

① A持续地测量从其相邻对等方接收数据的速率,并确定速率最高的4个相邻对等方。

② A就把文件块发送给这4个相邻对等方。每隔 10秒钟,A 还要重新计算数据率,然后可能修改这4个对等方。在 BT 的术语中,这4个对方叫作已疏通的或无障碍的(unchoked)对等方。更重要的是,每隔30秒,A要随机地找一个另外的相邻对等方B,并向其发送文件块。这样,A 有可能成为 B 的前4 位上传文件块的提供者。在此情况下,B也有可能向A 发送文件块。如果B 发送文件块的速率足够快,那么B 也有可能进入A的前4位上传文件块的提供者。这样做的结果是,这些对等方相互之间都能够以令人满意的速率交换文件块。

文章来源:https://blog.csdn.net/weixin_69884785/article/details/135062637
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。