组播和pp的分发管理模块的设计方案与实现.docx

组播和pp的分发管理模块的设计方案与实现.docx

《组播和pp的分发管理模块的设计方案与实现.docx》由会员分享，可在线阅读，更多相关《组播和pp的分发管理模块的设计方案与实现.docx（12页珍藏版）》请在冰豆网上搜索。

组播和pp的分发管理模块的设计方案与实现

基于组播和P2P的文件分发管理模块的设计与实现

满萍马严

<北京邮电大学信息网络中心，北京100876）

摘要：

本文对CNGI研究课题“组播与P2P相结合的文件分发系统”进行了简要介绍。

通过对该系统文件管理模块的总体设计和详细设计，实现了基于IPv6组播与P2P技术的相结合。

该系统借助JXTA平台实现P2P的基本功能：

节点搜索、节点资源搜索、节点间的通讯和文件的统一管理等，实现了尽量利用可靠的组播并利用P2P实现跨组播域的信息传输。

论文最后通过对管理模块在不同环境下的测试数据进行分析，表明该设计思想的有效性。

关键词：

P2P；IPv6；JXTA；文件管理

ADesignandImplementationofFileDistributionManagementModuleBasedonMulticastandP2P

MANPing，MAYan

（NetworkInformationCenter,BeijingUniversityofPostsandTelecommunication,Beijing100876>

Abstract：

ThispaperintroducesaCNGIresearchproject“AFILEDISTRIBUTINGSYSTEMBYTHECOOPERATIONOFIPMULTICASTANDP2P”.Throughcarefuldesignofthefilemanagementmoduleofthesystem,acombinedfunctionofIPv6multicastandP2Pfulfilledcouldberealized.ByusingtheJXTAP2Pplatform,thesystemimplementedthebasicfunctionsofnodesearching,noderesourcesearching,communicationamongnodesandunifiedfilemanagement.Thesystemusesthemulticastfunctionifitisavailable,thenP2Pfunctionisusedtodeliverinformationacrossmulticastdomain.Thefinalpartofthispaperrevealedthesuccessfuldesignofthefilemanagementmodulebyanalyzingthetestresultsindifferentenvironment.

Keywords：

P2P。

IPv6。

JXTA。

filemanagement

1引言

本课题作为“CNGI大规模路由和组播研究实验”的子工程，主要目的是验证IPv6环境下的P2P可行性及性能、大规模IPv6组播的性能，以及在IPv4和IPv6组播下组播性能的对比。

因此，设计和实现“组播和P2P相结合的文件分发系统”是本工程的主要内容，性能比对测试是本工程的目的。

本课题的创新点是IPv6组播与P2P技术的相结合，即利用P2P实现可靠的组播和跨域的组播。

一方面利用IP层的组播技术解决应用层服务的一些缺陷，有效的利用网络资源；另一方面提出并实现一个可控、可管的P2P文件分发应用系统，对实现P2P应用的可控制性、可管理性进行有益的尝试。

2模块的总体设计

2．1系统总览

如图1所示，在系统把整个应用分为八大模块。

图1系统体系结构

下面简要介绍这八大模块的主要功能：

<1）消息处理模块：

它包括系统消息的组播单播接收发送模块，以及消息处理机。

<2）数据处理模块：

包括组播、单播接收和发送模块，以及一个数据收发控制器。

<3）文件资源读写模块：

主要是对文件的读写操作。

<4）认证模块：

主要是检测用户的合法性，跟后台数据库还有一定的联系，可能要对数据库有查询、更新等操作。

<5）计费模块：

该模块目前只作为一个接口存在，以便日后方便扩展，同时还可以跟认证模块联系起来，比如说AAA认证。

<6）资源管理模块：

该模块由作者负责，后文会有详细介绍。

<7）即时消息模块：

它的任务就是处理一些即时消息，如对等体

<8）用户管理界面：

是人机的接口，主要提供给用户一个可视的友好界面。

[1]

2．2管理模块基本功能介绍

本模块也是本系统的关键模块，系统的可管理性就在本模块集中体现。

主要功能是记录并管理网络共享资源、维护网络拓扑，发现和探测网络资源等，同时还留有网管接口，以便本系统日后扩展。

P2P资源管理功能。

这一功能计划分以下几个步骤：

<1）首先实现子网内部对等组、对等点和管道的发现，并实现子网内对等点之间的通信；

<2）实现跨子网的对等组、对等点和管道的发现，实现跨子网的对等点之间的通信；

<3）实现完整的P2P资源管理功能。

2．3管理模块总体设计

P2P通信模块用于数据模块启动前，应用系统的配置和文件信息的传送。

只通过P2P通信，才能接收到其它Peer的配置参数，才能把自己的配置参数公布在JXTA网络上。

在此应用中，Peer可分为三种，文件源Peer（SourcePeer>、接收Peer（ReceivePeer>、代理Peer

文件源Peer是文件的最初来源，它在整个应用中是唯一的，即整个应用中，只有一个文件的来源。

它主要负责对文件进行分片，然后把分好的片按照规则封闭成数据包，以组播形式发送到应用网络上；同时文件源还需对其他Peer发出的分片请求做出应答，以重新发送请求方丢失的分片。

代理Peer在应用中的角色可从两个角度来看：

一方面在同一组播域中，代理Peer扮演着和文件源Peer相同的角色，即它是该组播域的“文件源”负责把从文件源Peer获得的文件以组播形式发送到该组播域的其他结点，另一方面代理Peer也是一个特殊的接收Peer，它以单播的形式从文件源或其他Peer处取得文件分片，并力图保证文件的完整性。

接收Peer在大规模的应用中所占的比例比较大，应用中绝大多数对等体都属于这种类型。

它的功能一方面是从处于同一组播域的文件源Peer或代理Peer处以组播方式接收文件分片，另一方面以单播方式从其他Peer取得丢失的分片。

3应用管理详细设计

应用管理目的是实现P2P功能，为了使应用能够简单有效、稳定安全地工作，为了降低设计开发周期，通过比较论证决定采用JXTA平台来实现主要功能：

资源搜索。

3．1JXTA平台

3．1．1JXTA平台简介

JXTA是工程创始人Sun首席科学家BillJoy二十多年酝酿的结晶，“JXTA技术是网络编程和计算的平台，用以解决现代分布计算尤其是点对点计算中出现的问题。

”[2]

JXTA是为了构建P2P网络而制订的一组协议，是处理构建P2P网络所碰到的问题的解决方法，JXTA标准协议规范介绍如下：

“JXTA由六个协议组成，这些协议是专为特定的、分布式的、对等的网络计算而设计的。

使用这些协议，Peer可以互相合作来建立自我组织、自我管理的对等组，而不必关心它们在网络中所处的位置，也不需要集中的管理机构。

”

3．1．2JXTA协议

JXTA在JXTA协议规范中定义了它的协议。

此规范描述了Peer间如何通信和交互，它并未描述实现的细节或如何编写P2P应用程序，下面是JXTA协议的列表，其中包含了协议名称的首字母缩略词，这六个协议如下图所示。

[3]

图2JXTA的核心协议

<1）PeerDiscoveryProtocol（PDP>对等点发现协议：

Peer使用这个协议来发现被发布出来的JXTA资源。

由于广告就是代表着发布的资源。

<2）PeerResolverProtocol（PRP>对等点解读协议：

在通常情况下，peer向其它peer发送查询消息来定位服务或者内容。

PRP会将查询的格式标准化。

<3）PeerInformationProtocol（PIP>对等点信息协议：

可以在JXTA环境中对一个peer发出ping消息。

<4）PeerMembershipProtocol

对等点使用该协议来加入和离开peergroup。

<5）PipeBindingProtocol（PBP>管道绑定协议：

peer使用管道来连接服务。

一个peer可以动态的将绑定pipe的一端连接服务。

Peer可以新建pipe，把它绑定到现存的pipe上，或是取消对pipe的绑定。

<6）EndpointRoutingProtocol（ERP>终点路由协议：

这个协议帮助peer将消息路由至目的地。

[4]

3．2模块详细设计

3．2．1管理模块

工作流程图<由于篇幅原因只列出了接收方流程图）见图4：

3．2．2详细说明

<1）启动JXTA

每个对等体启动时，都要先启动JXTA平台。

如果某一对等体位于防火墙之后，则启动时，高级选项中HTTPEnable选项必须配置成Enable。

<2）加入NetPeerGroup组

对等体必须加入到NetPeerGroup组。

该组是默认的对

图4接收方流程图

等组，任何其他对等组都是改组的子集。

<3）加入MulticastGroup组

Multicast组只能由文件源创建。

这里分两种情况：

一种是对等体本身就是文件源Peer，那么该对等体必须负责创建MulticasgGroup组。

当文件源Peer启动时，先检查本地缓存中是否有MulticastGroup的组通告，如果有，则直接加入到该组，否则必须创建一个MulticastGroup对等组，并把该组发布到JXTA网络上，并加入该组。

另一种情况是对等体是代理Peer或接收Peer那么该对等体也应该先检查本发缓存，看有没有MulticastGroup的组通告，如果有则试着加入到该组，如果没有，则远程发送发现请求，来远程发现MulticastGroup组。

如果发现不成功，则重新尝试N次后，退出该应用，并报告未发现对等组的错误。

<4）创建输入管道端点，并发布

加入MulticastGroup组后，对等体就开始创建本地的输入管道端点，整个应用过程中，对等体以此管道端点与其他对等体建立管道，接收其他对等体的P2P消息。

<5）发现其他对等体管道通告

如果对等体是文件源Peer则直接进行步骤7和8。

因为文件源Peer是文件的最初发源地。

除文件源Peer之外的对等体必须发现其他对等体的管道通告。

以从其他对等体处获得组播地址和端口信息，以及将要发送的文件信息。

<6）向其他对等体发送请求并等待应答

当对等体发现了其他对等体的管道通告后，就可以与这些对等体进行通信了。

如果所发现的管道通告中只有文件源Peer的管道通告,那么该对等体同文件源Peer建立管道，并向文件源Peer发送请求。

如果所发现的管道通告中既包括文件源Peer的管道也包括其他类型Peer管道，则该对等点优选选择其他类型Peer的管道端点建立管道并发送请求。

当对等体向某个对等体发送请求后，便等待该对等体的响应。

如果经过一段时间延时，还未收到响应，则重新发送请求。

直到重试N次后，如果仍未响应，则认为该对等体已经退出该应用。

在这里，延时的时间应由应用的范围决定。

如果应用是在一个子网内，则时间可设置得稍微短些，例如3秒钟。

如果是在Internet上应用，则延时时间还应更长些，以给被请求的对等体足够的时间进行响应。

对等体收到应答后，设置本地文件管理器和应用参数准备接收数据同时监听其他对等体的P2P请求。

<7）开启数据传送模块

这里也分为两种情况：

第一种情况，如果该对等体是文件源Peer,则经过一段时间的延时后再开启数据传送块，以给其他对等体充足的时间来接收到应用所必须的参数<组播端口、组播地址、文件信息等）延时过后，该文件源Peer开始发送组播数据并等待其他对等体的数据请求和P2P请求。

第二种情况，如果该对等体是代理Peer或接收Peer则该对等体立即开启数据传送模块，以做好接收组播数据的准备。

当数据模块执行完毕后，应用并不立即退出，而是继续等待，直到用户手动关闭为止。

目的是为了继续响应其他对等体的数据请求和P2P请求。

<8）接收和响应其他对等体的请求

当连接建立完毕之后，对等体就监听并响应其他对等体发送的P2P请求了。

当对等体接收到其他对等体的P2P请求时，从请求通告中提取出请求者的管道端点通告信息，然后建立一个输出端点，与请求方的输入端点建立管道，并把应用的参数和将要传送的文件信息传送给请求对待体。

传送完毕后，继续等待下一个请求。

3．2．3消息格式定义

P2P消息主要分两类：

一类是由各种服务所使用的通告为内容的消息，这类消息由JXTA自动维护，因此不需要我们设计；另一类是以应用参数和文件信息为内容的消息，这类消息需要发送对等体和接收对等体按照统一的格式进行传递。

1、请求消息格式设计。

请求方的输入管道端点通告

这里包含请求方的输入管道端点通告，是为了让被请方应答时直接跟该管道端点建立通信。

2、应答消息格式<这里只列出部分消息格式

“4”或“6”

组播数据端口

“4”或“6”

组播数据端口

数据字段最大长度

数据包包头长度

一个数据包长度

要传送的文件的ID

要传送的文件的大小

是否只读

是否隐藏

4测试环境设计与测试数据分析

4．1测试环境

4．1．1同一网段内

在同一网段中，主机的操作系统WindowsXP、Windows2000、Windows2003，手工设置IPv4地址。

网络拓扑见下图。

图5同网段测试拓扑图

4．1．2不同网段间

路由器：

日立GR2000_2B_IPv6，3个接口

接口1：

fe2/1,ipv6address:

2001:

254:

1a03:

1:

:

/64,不在组播域中，IPv6地址自动获取；

接口2：

fe2/2,ipv6address:

2001:

254:

1a03:

2:

:

/64,在组播域中，IPv6地址自动获取；

接口3：

fe2/3,ipv6address:

2001:

254:

1a03:

3:

:

/64,在组播域中，IPv6地址自动获取。

网络拓扑见图6，路由器的3个接口中，有两个在同一组播域中，另外一个不在。

测试时，在接口1的子网中添加一个汇聚点，通过它从其它组播域获取文件，进而，该组播域中的其它主机就可以以组播的形式从汇聚点获取文件。

为说明简单，暂且将与接口1相连的网段称为网段1，其它两个称为网段2和3。

汇聚点在网段1中，文件源在网段2中。

图6测试拓扑图

4．2测试结果

4．2．1同一网段内

1．SourcePeer

<1）JXTA的基本配置

首先配置Basic选项卡，填入PeerName，Password等信息；Advanced选项卡采用默认设置；Rendezvous/Relays选项卡也选择默认设置。

<2）运行结果

首先，发现并加入NetPeerGroup组；然后在缓存中查找MulticastGroup，已存在，则加入之；显示出MulticastGroup的相关信息，同时显示加入组成功的信息；然后，在缓存中查找InputPipe信息，若不存在，则创建，若存在，则显示其信息；并且，显示成功创建InputPipe信息，同时等待其它Peer的Request；收到其它Peer的Request；向请求Peer发送Response；继续等待其它Peer的请求。

2．ReciverPeer

<1）JXTA的基本配置

Basic选项卡：

与SourcePeer相同；Advanced选项卡：

将Http的端口号改为手工配置，8000；Rendezvous/Relays选项卡：

采用默认值。

<2）运行结果

首先，发现并加入NetPeerGroup组；接着，发现并加入MulticastGroup组；查找管道信息；创建自己的InputPipe；连接到文件源并向其发送请求；等待文件源的回应，显示Response内容，并将其写入配置文件。

4．2．2不同网段间

JXTA的配置与同一网段的基本一致，只需在Rendezvous/Relays中的Rendezvoussendpeers中添加已设置好的汇聚Peer的地址就可实现信息转发。

4．3结果分析

通过对实验数据的分析发现仍存在一些问题，<1）在同一网段的情况：

一般很容易实现，同时开启多个Peer的时候也可以顺利进行。

但是文件源的Peer要较其它Peer早开启，若晚开启或者同时开启都会出现找不到组的情况。

<2）不同网段间的情况：

需设置汇聚点方可通讯。

<3）跨多个路由的情况：

由于网络的复杂性，所以会影响到速度，但可以实现文件源的发现,只是速度上较同一网段上的稍慢了一些。

今后将在此基础上对系统的性能、安全性、对多媒体信息的传输等方面进行深入研究。

参考文献

[1]丘子隽.IP组播的概念与应用.世界宽带网络,2005:

25-30.

[2]JXTAJavaStandardEdition2.3.4Javadoo[EB/OL]．http:

//platform.jxta.0rg/n0nav/java/api/jndex.html,2005.

[3]张智,李瑞轩.基于JXTAP2P的Web服务发现模型研究[J].计算机工程与应用,2005,41（19>:

137-139.

[4]GongL．JXTA:

ANetworkProgrammingEnvironment[J]．IEEEInternetComputing,2001,15（3>:

88-95．