基于ＩＰｖ６的Ｐ２Ｐ組播應(yīng)用的研究與實現(xiàn)

摘要：介紹IPv6組播和P2P多播技術(shù)，分析FreePastry的路由算法，重點改進(jìn)對象EpochInetSocketAddress對源路由節(jié)點地址的管理方法，在Fedora Core 6系統(tǒng)環(huán)境下雙棧技術(shù)的運用，以及在IPv6環(huán)境下設(shè)計并實現(xiàn)了基于P2P的組播應(yīng)用。MTAP6由P2P重疊網(wǎng)和接入網(wǎng)兩個部分組成，其中重疊網(wǎng)部分采用基于P2P的應(yīng)用層組播技術(shù)，接入網(wǎng)部分采用基于IPv6的組播技術(shù)。最終實現(xiàn)了以視頻會議、視頻點播、遠(yuǎn)程教育為特色的新型多媒體組播應(yīng)用

關(guān)鍵詞：P2P；IPv6；雙棧；路由地址；重疊網(wǎng)；組播；媒體傳輸

中圖分類號：TP393 文獻(xiàn)標(biāo)識碼：A文章編號：1009-3044(2008)17-21403-04

1 概述（增加IPv6網(wǎng)絡(luò)中p2p組播）

隨著全球互聯(lián)網(wǎng)（Internet）的迅猛發(fā)展，網(wǎng)絡(luò)軟硬件技術(shù)的快速提升，寬帶網(wǎng)絡(luò)迅速普及。以視頻會議、視頻點播、遠(yuǎn)程教育為代表的新型多媒體組播應(yīng)用成了寬帶網(wǎng)絡(luò)的寵兒，日益受到人們關(guān)注。目前IPv4組播的服務(wù)模型仍然存在不足，無法在Internet上得到廣泛部署。因此，對新的組播替代方案的研究非常迫切。基于IPv6組播和P2P多播技術(shù)就是其中之一。

當(dāng)前，P2P在IPv6的應(yīng)用很少，大多不支持，本論文研究的目的就是使基于IPv6組播和P2P多播技術(shù)應(yīng)用能得到進(jìn)一步的發(fā)展。在IPV6環(huán)境下發(fā)展P2P能揚長避短，解決其可擴(kuò)展性問題和安全問題。本論文通過對FreePastry系統(tǒng)的改進(jìn)， 在linux系統(tǒng)中采用雙棧技術(shù)，使其在支持IPv6的基礎(chǔ)上，設(shè)計實現(xiàn)了一套基于IPv6的P2P組播應(yīng)用系統(tǒng)。

MAPN6由P2P重疊網(wǎng)和接入網(wǎng)兩個部分組成，其中重疊網(wǎng)部分采用基于P2P的應(yīng)用層組播技術(shù)，接入網(wǎng)部分采用基于IPv6的組播技術(shù)。

2 關(guān)鍵技術(shù)

2.1 IPv6組播

IPv6組播[3]在原理上繼承了IPv4 的組播思想，首先地址變成了128 位的，其次為了在IPv6 中更好地支持組播，將IPv4 中的廣播地址也融入到組播之中。組播內(nèi)容主要包括3 個：組播地址結(jié)構(gòu)、鏈路組管理協(xié)議和組播路由協(xié)議。

IPv6 組播的地址結(jié)構(gòu)分配如圖1 所示。IPv6 組播地址前綴為FF::/8 ，接下來的8 位分別定義存活時間(Lifetime) 和組播地址范圍(Scope) ，Lifetime = 0 時表示該地址為永久分配的組播地址，由IANA 定義并注冊； Lifetime = 1 時表示臨時地址。Scope 用于限定組播的區(qū)域，當(dāng)Scope 值為1、2、5、8 和E 時，分別代表組播區(qū)域為：節(jié)點(node) 范圍、鏈路(link) 范圍、站點(site) 范圍、組織(organization) 范圍和全球(global) 范圍。

組播分組和單播分組一樣，以盡力傳輸?shù)姆绞桨l(fā)送分組給一組主機(jī)。接收分組的組成員是動態(tài)變化的，任何時候都可能有主機(jī)加入或退出組。組播不限定接收者的位置、個數(shù)，同一節(jié)點也可以加入任意數(shù)量的組播組。圖2是IPv6組播結(jié)構(gòu)示意圖。

在使用組播機(jī)制時，路由器之間相互學(xué)習(xí)組成員信息，發(fā)送者不必知道接收者的情況，發(fā)送分組在接收者的路徑不同時才發(fā)生復(fù)制。無論組播的接收者有多少，組播數(shù)據(jù)量是一定的。這樣可以適應(yīng)組播拓?fù)浣Y(jié)構(gòu)的不斷變化，節(jié)省大量的帶寬，避免網(wǎng)絡(luò)擁塞，提高服務(wù)性能。

2.2 基于P2P的應(yīng)用層組播

應(yīng)用層組播[4]，就是在應(yīng)用層實現(xiàn)組播功能而不需要網(wǎng)絡(luò)層的支持。這樣就可以避免出現(xiàn)由于網(wǎng)絡(luò)層遲遲不能部署對組播的支持而使組播應(yīng)用難以進(jìn)行的情況。應(yīng)用層組播需要在參加的應(yīng)用結(jié)點之間實現(xiàn)一個可擴(kuò)展的，支持容錯能力的重疊網(wǎng)絡(luò)，而基于DHT的發(fā)現(xiàn)機(jī)制正好為應(yīng)用層組播的實現(xiàn)提供了良好的基礎(chǔ)平臺。

Overlay組播將組播功能從路由器轉(zhuǎn)移到端系統(tǒng)，由端系統(tǒng)來完成所有組播服務(wù)的功能，如組管理、成員管理、分組復(fù)制和轉(zhuǎn)發(fā)。所有組播成員構(gòu)成一個疊加在IP網(wǎng)絡(luò)之上的功能性網(wǎng)絡(luò)，在這個網(wǎng)絡(luò)中構(gòu)建Overlay組播樹。

為了適應(yīng)多源組播的特點，采用了集中式算法下的Mesh-first組播樹構(gòu)造方式，在集中控制的方式下，每個組播組在Overlay網(wǎng)絡(luò)中生成一個RP節(jié)點（Rendezvous Point），它負(fù)責(zé)記錄Overlay網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)，在節(jié)點創(chuàng)建或加入組播組的過程中，RP會收集節(jié)點的所有定制信息，并根據(jù)這些信息計算和生成相應(yīng)的組播分發(fā)樹。

2.2.1 節(jié)點加入

與單源Overlay組播路由算法不同，多源的Overlay組播路由算法在有新節(jié)點加入時，匯聚節(jié)點要完成如下兩步操作：第一步是測試新節(jié)點能否按照自己的服務(wù)定制要求加入到已有的各個組播樹中。第二步是檢查新的節(jié)點加入后，網(wǎng)絡(luò)中現(xiàn)有的各個節(jié)點是否能夠按照各自的定制要求組建一棵以新節(jié)點為源的組播樹。如果兩步都能通過，則將新節(jié)點加入組播組并更新系統(tǒng)中的數(shù)據(jù)分發(fā)關(guān)系。

2.2.2 節(jié)點離開和失效處理

節(jié)點離開或失效（如系統(tǒng)突然崩潰）對Overlay組播樹的影響較為明顯。當(dāng)節(jié)點離開組播組時，它將向RP節(jié)點發(fā)送Leave報文進(jìn)行通告。RP節(jié)點刪除以該節(jié)點為根的源點樹，并讓該加點下所有孩子節(jié)點重新加入其它源點樹中，最后更新組播路由結(jié)構(gòu)。若節(jié)點失效，RP定期更新拓?fù)鋾r將發(fā)現(xiàn)失效節(jié)點，并采取同樣操作。但是當(dāng)退出或失效節(jié)點是RP節(jié)點時，這就需要設(shè)置一個RP備用節(jié)點，來維持系統(tǒng)的正常動作。

3 IPv6中Pastry路由算法的改進(jìn)

Pastry算法[1]是微軟研究院提出的可擴(kuò)展的分布式對象定位和路由算法，可用于構(gòu)建大規(guī)模的自組織的P2P系統(tǒng)。任何與Internet連接的主機(jī)都可以通過運行Pastry加入到他的P2P網(wǎng)絡(luò)中。FreePastry是美國休斯頓萊斯（Rice）大學(xué)基于Pastry算法發(fā)布的Pastry開源軟件包。

3.1 Pastry路由算法

在Pastry協(xié)議中，每個節(jié)點擁有一個128位的標(biāo)識NodeId，為了保證NodeId的唯一性，一般由節(jié)點的網(wǎng)絡(luò)標(biāo)識（如IP地址）經(jīng)過散列得到。Pastry中的每個節(jié)點擁有一個路由表，一個鄰居節(jié)點集合和一個葉子節(jié)點集合，它們一起夠成了節(jié)點的狀態(tài)表。

Pastry的路由過程[2]如下。首先，路由查詢消息中將攜帶被查詢鍵值，即對象ID。當(dāng)收到一條消息時，結(jié)點首先檢查消息的關(guān)鍵字是否落在葉子結(jié)點集合中。如果是，則直接把消息轉(zhuǎn)發(fā)給對應(yīng)的結(jié)點，也就是葉子結(jié)點集合中結(jié)點標(biāo)識和關(guān)鍵字最接近的結(jié)點。否則就從路由表中根據(jù)最長前綴優(yōu)先的原則選擇一個節(jié)點作為路由目標(biāo)，轉(zhuǎn)發(fā)路由消息。如果不存在這樣的節(jié)點，當(dāng)前節(jié)點將會從其維護(hù)的所有鄰居節(jié)點集合（包括路由表葉子節(jié)點集合及鄰居節(jié)點集合中的節(jié)點）中選擇一個距離該鍵值最接近的節(jié)點作為轉(zhuǎn)發(fā)目標(biāo)。

Pastry路由的偽代碼如下：

if(L-|L/2|≤D≤L|L/2|)

//D在葉子節(jié)點集合的范圍內(nèi)

forward to Li，s.th.|D-Li| is minimal;

else

//使用路由表

Let l=shl(D，A);

if(RlDl≠1)

forward to RlDl

else

//特殊情況

forward to T∈L∪R∪M，s.th.;

shl(T，D)≥l，

|T-D|<|A-D|;

其中符號定義如下：

Rli代表路由表的第l(下標(biāo))行第i(上標(biāo))列；

Li代表在葉子集中第i(下標(biāo))個最接近當(dāng)前nodeid的節(jié)點；

Dl代表key D的第l位數(shù)值；

Shl(A，B)代表A和B共享的前綴的長度；

3.2 Pastry路由改進(jìn)算法對IPv6的支持

Pastry作為分布式哈希表技術(shù)的代表，越來越愛到大家的關(guān)注。當(dāng)前，對FreePastry的應(yīng)用主要是基于IPv4環(huán)境的，對IPv6環(huán)境并不支持，隨著IPv6技術(shù)和需求不斷提高，Pastry從IPv4過渡到IPv6問題的解決已經(jīng)迫在眉睫。目前提出的IPv4到IPv6基本過渡技術(shù)中，主要包括有雙棧技術(shù)、隧道技術(shù)和協(xié)議翻譯（NAT-PT）技術(shù)等三種。其中雙棧技術(shù)是指在單個節(jié)點上同時支持IPv4和IPv6兩種協(xié)議。由于IPv6和IPv4是功能相近的網(wǎng)絡(luò)層協(xié)議，兩者都基于相同的物理平臺，而且加載于其上的傳輸層協(xié)議TCP和UDP也沒有任何區(qū)別，因此，支持雙協(xié)議棧的節(jié)點既能與支持IPv4協(xié)議的節(jié)點通信，又能與支持IPv6協(xié)議的節(jié)點通信。

新算法采用JAVA語言編寫， 源程序選用FreePastry2.0版本， 開發(fā)平臺是JDK1.6。通過對標(biāo)準(zhǔn)路由源碼分析， 其路由管理算法用類EpochInetSocketAddress實現(xiàn)。EpochInetSocketAddress標(biāo)識到遠(yuǎn)程IP地址的源路由。FreePastry使用EpochInetSocketAddress和網(wǎng)絡(luò)中其它節(jié)點進(jìn)行交互，通常情況下EpochInetSocketAddress是基于IPv4環(huán)境的，并且將一個IP地址、一個端口和一個8字節(jié)的epoch編碼所構(gòu)成。使用epoch的目的是要知道該節(jié)點自上次通信以來是否重啟，這樣應(yīng)用程序通過該信息就可以知道節(jié)點的狀態(tài)。因此修改類EpochInetSocketAddress中相應(yīng)的函數(shù)， 使之能夠識別從IPv6地址發(fā)來的數(shù)據(jù)。

FreePastry使用TCP協(xié)議來維護(hù)所有的overlay網(wǎng)絡(luò)以及應(yīng)用程序的通信；使用UDP協(xié)議進(jìn)行活躍節(jié)點的檢查。在使用TCP或UDP進(jìn)行通信時，要不斷將EpochInetSocketAddress序列化、解序列化以及計算序列化的長度以保證消息的正常傳輸。

FreePastry目前并不支持IPv6網(wǎng)絡(luò)環(huán)境，主要是由于在接受和發(fā)送消息時其路由地址是按照4字節(jié)的IP地址計算的，這樣在接收從IPv6地址發(fā)來的消息或者向IPv6目標(biāo)地址發(fā)送消息時就會錯。新算法在標(biāo)識路由地址時全部采用16字節(jié)的IPv6地址，在EpochInetSocketAddress地址序列化的過程中調(diào)整4字節(jié)的地址空間為16字節(jié)的地址空間，重新計算序列化長度，在解序列化的過程中由原來的讀取4字節(jié)的IP地址改為讀取16字節(jié)的IP地址，經(jīng)過這樣的調(diào)整，即可實現(xiàn)對IPv6地址的支持。

路由地址序列化過程的函數(shù)偽代碼如下：

serialize(buf) {

write route_numHops_numAddresses length to buf;

for(i=0;i

write IPv6_address to buf;

write port to buf;

}

write epoch to buf;

}

路由地址解序列化過程的函數(shù)偽代碼如下：

EpochInetSocketAddress build(buf)

{

read route_numHops_numAddresses length from buf;

for(i=0;i

read IPv6_address from buf;

read port from buf;

Route_Hop_InetSocketAddress[i]=new InetSocketAddress

(IPv6_address， port);

}

read epoch from buf;

return EpochInetSocketAddress(Route_Hop_InetSocketAddress，epoch);

}

計算序列化地址長度的函數(shù)偽代碼如下：

getSerializedLength() {

return epoch+route_numHops_numAddresses+

(route_numHops_numAddresses*(IPv6_address.length+port.length))

}

4 MTAP6的設(shè)計

本文設(shè)計實現(xiàn)的組播應(yīng)用系統(tǒng)，基于Overlay組播網(wǎng)絡(luò)技術(shù)，面向流媒體、文本等多種應(yīng)用，支持服務(wù)定制功能，能適應(yīng)Internet網(wǎng)絡(luò)的異構(gòu)性，并能對動態(tài)變化的網(wǎng)絡(luò)資源作自適應(yīng)控制。該原型系統(tǒng)完全基于Java平臺開發(fā)，實現(xiàn)了跨平臺的部署及應(yīng)用。

4.1 MTAP6的框架模型

Overlay組播系統(tǒng)的體系結(jié)構(gòu)主要分為兩類，一類是基于端系統(tǒng)的體系結(jié)構(gòu)，一類是基于代理服務(wù)器的體系結(jié)構(gòu)，本系統(tǒng)采用基于代理服務(wù)器的C/S層次結(jié)構(gòu)，它由Overlay網(wǎng)絡(luò)和接入網(wǎng)絡(luò)兩個部分構(gòu)成，其中Overlay網(wǎng)絡(luò)部分完成匯聚節(jié)點的選擇、組播樹的構(gòu)建等功能，接入網(wǎng)部分不參與Overlay組播路由的計算。圖3是基于代理服務(wù)器的組播系統(tǒng)體系結(jié)構(gòu)。

4.2 MTAP6的結(jié)構(gòu)模塊

原型系統(tǒng)代理服務(wù)器在實現(xiàn)設(shè)計上分為接入網(wǎng)部分和Overlay網(wǎng)絡(luò)部分兩大功能模塊，并通過代理服務(wù)器總控模塊將其聯(lián)系起來，如圖4所示。接入網(wǎng)服務(wù)模塊面向接入網(wǎng)絡(luò)，為最終客戶提供代理服務(wù)，覆蓋網(wǎng)服務(wù)模塊面向Overlay網(wǎng)絡(luò)，運行Overlay組播路由協(xié)議，提供組播服務(wù)。

4.3 控制信息的傳輸

該系統(tǒng)的控制信息采用了基于P2P網(wǎng)絡(luò)的傳輸方式，當(dāng)接入網(wǎng)中的客戶端上層應(yīng)用啟動以后首先生成相應(yīng)的控制信息，這些控制信息被傳輸?shù)交赑astry協(xié)議的P2P層，然后由Pastry提供的Message方法將其封裝為Pastry協(xié)議所用的通信格式，經(jīng)由Pastry的P2P路由發(fā)送到代理服務(wù)器端。代理服務(wù)器節(jié)點接收到Message消息后，向上傳送至Pastry，由Pastry解封裝還原為原始的控制信息，再向上交給服務(wù)器的總控模塊。總控模塊對控制信息進(jìn)行響應(yīng)處理，并把必要的信息再往下封裝成Message發(fā)送到P2P網(wǎng)絡(luò)中的其它節(jié)點。

4.4 媒體數(shù)據(jù)的傳輸

媒體數(shù)據(jù)采用JMF技術(shù)結(jié)合RTP/RTCP直接傳輸?shù)姆绞?，提高了?shù)據(jù)的傳輸效率。利用JMF獲取音頻和視頻并保存為多媒體文件，處理多媒體文件轉(zhuǎn)換文件格式，在互聯(lián)網(wǎng)上傳輸音頻和視頻數(shù)據(jù)流。實時傳輸協(xié)議（RTP）[5]是針對流媒體的一種傳輸協(xié)議，其目的是在一對一或一對多的情況下，提供時間信息和實現(xiàn)流同步，在快速和可靠的狀態(tài)下通過網(wǎng)絡(luò)傳輸時間極其敏感的數(shù)據(jù)。RTP獨立于網(wǎng)絡(luò)和運輸層協(xié)議，但是通常在UDP協(xié)議層上實現(xiàn)，利用UDP來傳送數(shù)據(jù)，當(dāng)應(yīng)用程序開始一個RTP會時將使用兩個端口：一個給RTP，一個給RTCP，RTP本身并不能為按順序數(shù)據(jù)報提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)。RTP在JMF中用于提供給用戶向其他網(wǎng)絡(luò)節(jié)點傳輸媒體流的方法。

4.5 接入網(wǎng)的IPv6組播

在接入網(wǎng)部分即客戶端采用IPv6組播技術(shù)，即一對多的組播應(yīng)用，群中有一個源點和多個宿點，源點就是代理服務(wù)器，宿點即是客戶端，這樣做的好處是：（1）向多位接收者發(fā)送相同的信息；（2）只在需要時進(jìn)行包復(fù)制，提高帶寬利用率；（3）收件人地址未知；（4）成員可以動態(tài)加入或退出

本系統(tǒng)采用基于代理服務(wù)器的兩層體系結(jié)構(gòu)，一個代理服務(wù)器同時為多個客戶端提供代理服務(wù)，但在Overlay網(wǎng)絡(luò)中構(gòu)成的組播轉(zhuǎn)發(fā)樹上，卻只是以這個代理服務(wù)器作為一個轉(zhuǎn)發(fā)節(jié)點出現(xiàn)，它有效控制了組播轉(zhuǎn)發(fā)樹容量的增長。代理服務(wù)器之間利用結(jié)構(gòu)化的P2P聯(lián)網(wǎng)協(xié)議Pastry構(gòu)成核心網(wǎng)絡(luò)拓?fù)洌∕esh），而組播路由的建立則采用網(wǎng)絡(luò)優(yōu)先（Mesh-first）的Overlay組播協(xié)議。這樣在保證系統(tǒng)可擴(kuò)展的前提下，對于具體的組播服務(wù)可以提供高效率的Qos組播路由。

5 結(jié)論

本論文介紹IPv6組播和P2P多播技術(shù)，分析FreePastry的路由算法，通過對現(xiàn)有Pastry系統(tǒng)的改進(jìn)，使之支持面向下一代的IPv6網(wǎng)絡(luò)。以視頻會議、視頻點播、網(wǎng)絡(luò)教育等為主要內(nèi)容的P2P組播應(yīng)用越來越受到人們的重視，基于P2P的Overlay組播與IPv6組播相結(jié)合更是當(dāng)前發(fā)展的潮流，由于IPv6網(wǎng)絡(luò)的應(yīng)用仍受到一定的限制，如何使本系統(tǒng)既支持IPv4環(huán)境，又支持IPv6環(huán)境是本系統(tǒng)今后重點解決的問題。

參考文獻(xiàn)：

[1] Antony Rowstron，Peter Druschel.“ Pastry: Scalable， distributed object location and routing for large-scale peer-to-peer systems”Appears in Proc. Of the 18th IFIP/ACM International Conference on Distributed Systems Platforms. Heidelberg，Germany，November 2001.

[2] 楊天路，劉宇宏，等.“P2P 網(wǎng)絡(luò)技術(shù)原理與系統(tǒng)開發(fā)案例”，人民郵電出版社，2007.6.

[3] 李振強(qiáng)，趙曉宇，馬嚴(yán)，等.“IPv6技術(shù)揭密”，人民郵電出版社，2006.4.

[4] 吳家皋，葉曉國，姜愛全.“異構(gòu)環(huán)境下覆蓋組播網(wǎng)絡(luò)路由算法的研究”.軟件學(xué)報，2005，16(6):1112-1120.

[5] H.Schulzrinne，GMD Fokus，S.Casner.A Transport Protocol for Real-Time Applications. RFC1889，January 1996.

注：本文中所涉及到的圖表、注解、公式等內(nèi)容請以PDF格式閱讀原文