專利名稱：用組播和單播協(xié)議可靠傳輸數(shù)據(jù)的方法及接收數(shù)據(jù)的主機的制作方法
技術(shù)領(lǐng)域：
本發(fā)明屬于通信技術(shù)領(lǐng)域，涉及網(wǎng)絡(luò)中的數(shù)據(jù)傳輸，特別是一種在數(shù)據(jù)網(wǎng)絡(luò)中用單播協(xié)議傳輸補充組播協(xié)議的數(shù)據(jù)傳輸方法，適用于所有具有單播和組播通訊模式的網(wǎng)絡(luò)和網(wǎng)絡(luò)協(xié)議。
背景技術(shù)：
目前在數(shù)據(jù)網(wǎng)絡(luò)中傳輸數(shù)據(jù)分為三大模式，第一種是單播(unicast)模式，它是一對一的通訊模式，例如，Internet就是以這種通信模式為主；第二種是廣播broadcast模式，它是一對所有的模式，所有在網(wǎng)上的主機無論其是否需要都收到廣播，廣播信息在網(wǎng)絡(luò)上進行無條件復(fù)制，由于其浪費資源所以廣播方式被限制在小型局域網(wǎng)的范圍內(nèi)；第三種模式是組播模式(multicast，國內(nèi)也有將其翻譯成多目傳送模式、多點傳送模式、多播的模式)，組波模式是兼具上述兩種模式優(yōu)點的通訊方式，是一對多的通訊方式，這里的多指的是有需要的多個主機，信息在網(wǎng)絡(luò)中由路由器或三層交換機進行按條件按需要的復(fù)制，所有有需要的主機通過發(fā)送請求獲得復(fù)制的信息，唯一的缺點就是在傳輸過程中發(fā)生的丟包難以補充修復(fù)。
目前的寬帶網(wǎng)的結(jié)構(gòu)特點是主干網(wǎng)絡(luò)帶寬遠小于所有用戶接入帶寬之和，在這種網(wǎng)絡(luò)結(jié)構(gòu)中，如果只用單播協(xié)議傳輸數(shù)據(jù)、為客戶提供寬的服務(wù)必然會存在客戶帶寬無法得到滿足的情況。單播傳輸協(xié)議提供寬帶服務(wù)需要兩個等式，一個是網(wǎng)絡(luò)主干總帶寬＝所有客戶接入帶寬之和；另一個是所有服務(wù)器總帶寬＝所有客戶機總帶寬之和。要在宏觀上實現(xiàn)這兩個等式幾乎是不可能完成的任務(wù)，雖然BT技術(shù)運用P2P的原理繞過了服務(wù)器的壓力問題，但是它無法繞過網(wǎng)絡(luò)主干的壓力，對目前寬帶網(wǎng)主干造成了極大的壓力，以至于有ISP封了BT端口。CDN技術(shù)能稍微緩解這一狀況，但其眾多服務(wù)器的高昂的成本注定其不可能解決根本問題。
解決上述問題的方法是大規(guī)模推廣使用組播協(xié)議，現(xiàn)行的組播協(xié)議用網(wǎng)絡(luò)中的路由器按需對信息進行即時復(fù)制，具有能節(jié)省網(wǎng)絡(luò)和服務(wù)器資源的優(yōu)點，但是組播協(xié)議存在一個致命的缺陷就是可靠性差，由于其在傳輸過程中，對于丟包沒有重傳機制，所以利用組播協(xié)議傳輸?shù)臄?shù)據(jù)是不可靠的，這種不可靠傳輸特性嚴重阻礙了組播協(xié)議的推廣使用，而且在但短期內(nèi)似乎無法解決。目前正在討論的可靠組播協(xié)議試圖通過原來的組播地址進行補包重傳，雖說在小規(guī)模范圍內(nèi)其技術(shù)可行，但在大規(guī)模的組播范圍內(nèi)由于其技術(shù)的復(fù)雜性和實現(xiàn)過程可靠性問題一直阻礙了其應(yīng)用，所以在大規(guī)模的組播范圍內(nèi)這種方式明顯是不現(xiàn)實和不劃算的。
發(fā)明的內(nèi)容本發(fā)明的目的之一是提供一種在數(shù)據(jù)網(wǎng)絡(luò)中綜合運用組播和單播協(xié)議傳輸數(shù)據(jù)的方法，以解決組播協(xié)議傳輸數(shù)據(jù)可靠性差的問題；目的之二是提供一種接收數(shù)據(jù)的接收主機，以實現(xiàn)對傳送數(shù)據(jù)的接收。
本發(fā)明的技術(shù)方案是這樣實現(xiàn)的本發(fā)明適用于所有具有單播和組播通訊模式的網(wǎng)絡(luò)和網(wǎng)絡(luò)協(xié)議，由于現(xiàn)行的網(wǎng)絡(luò)協(xié)議基本上都是用TCP/IP協(xié)議，為了便于理解就以IP組播和IP單播為例來說明，但并不表示本發(fā)明局限于IP網(wǎng)絡(luò)。
本發(fā)明提出的在數(shù)據(jù)網(wǎng)絡(luò)中綜合運用組播和單播協(xié)議可靠傳送數(shù)據(jù)的方法是一種完全采用單播協(xié)議對組播數(shù)據(jù)流的丟包進行補包的方式，這種補包方式可以完全獨立于組播協(xié)議，使用現(xiàn)有的組播協(xié)議傳輸，對于傳輸過程中的丟包由單播協(xié)議完成補包工作，此補包流程也可以嵌入將來的IP協(xié)議中。該數(shù)據(jù)傳輸?shù)倪^程包括發(fā)送和接收，其中，所述的發(fā)送數(shù)據(jù)過程如下a.發(fā)送或轉(zhuǎn)發(fā)組播數(shù)據(jù)的主機發(fā)送至少一條組播數(shù)據(jù)流；b.約定地址的補包主機使用至少一個約定的單播地址接收來自接收數(shù)據(jù)的主機的補包請求；c.約定地址的補包主機接收并識別補包請求，并按照請求的標尺刻度從存儲器中定位并找到相應(yīng)的數(shù)據(jù)；d.約定地址的補包主機找到相應(yīng)的數(shù)據(jù)后，以單播協(xié)議向請求補包的接收數(shù)據(jù)的主機發(fā)送補包數(shù)據(jù)；所述的接收數(shù)據(jù)過程如下a.接收數(shù)據(jù)的主機加入至少一個組播組，接收組播數(shù)據(jù)流的數(shù)據(jù)；b.接收數(shù)據(jù)的主機在接收組播數(shù)據(jù)流的過程中不斷監(jiān)測是否有錯包和丟包數(shù)據(jù)；c.接收數(shù)據(jù)的主機發(fā)現(xiàn)錯包和丟包后，以單播協(xié)議向約定地址的補包主機發(fā)出補包請求；d.接收數(shù)據(jù)的主機將接收到的有丟包的組播數(shù)據(jù)與單播補包數(shù)據(jù)進行整合。
實現(xiàn)本發(fā)明接收數(shù)據(jù)方法的主機包括如下幾個功能模塊存儲模塊，用于存儲接收到的數(shù)據(jù)；組播接收模塊，用于接收組播數(shù)據(jù)流的數(shù)據(jù)，并將接收到的這些數(shù)據(jù)存儲到存儲模塊中；丟包判斷及補包控制模塊，用于判斷所收到的組播數(shù)據(jù)流的數(shù)據(jù)是否發(fā)生丟包，并控制單播收發(fā)模塊進行補包；單波收發(fā)模塊，用于以單播協(xié)議向補包服務(wù)器發(fā)送補包請求，并接收補包服務(wù)器發(fā)來的補包數(shù)據(jù)；再將收到的補包數(shù)據(jù)交給丟包判斷及補包控制模塊與存儲模塊中的丟包數(shù)據(jù)進行整合。
本發(fā)明中有關(guān)技術(shù)術(shù)語的含義及內(nèi)容進一步解釋如下1.轉(zhuǎn)發(fā)設(shè)備是指在數(shù)據(jù)網(wǎng)絡(luò)中轉(zhuǎn)發(fā)、復(fù)制數(shù)據(jù)信息的設(shè)備，該轉(zhuǎn)發(fā)設(shè)備可以是三層交換機、二層交換機、CDN結(jié)點服務(wù)器等設(shè)備。
2.快速存儲器是指能夠快速存取數(shù)據(jù)的存儲器。在當前的技術(shù)條件下，內(nèi)存屬于快速存儲器；硬盤、光盤屬于慢速存儲器，閃存的速度介于兩者之間，既可以當快速存儲器用，也可以當慢速存儲器用。不排除將來技術(shù)的發(fā)展會有新型的存儲器成為快速存儲器或慢速存儲器。例如，現(xiàn)在正在研究的鐵電存儲器和全息存儲器等。
3.主機是指網(wǎng)絡(luò)中的那些有能力對數(shù)據(jù)信息進行處理、復(fù)制和轉(zhuǎn)發(fā)的設(shè)備，例如服務(wù)器、客戶機、網(wǎng)絡(luò)路由器、交換機等設(shè)備都可以統(tǒng)稱為主機。
4.發(fā)送或轉(zhuǎn)發(fā)組播數(shù)據(jù)的主機在網(wǎng)絡(luò)中提供組播數(shù)據(jù)源的主機就是發(fā)送組播的主機，例如服務(wù)器。在網(wǎng)路中向下一級網(wǎng)絡(luò)路由器或客戶機轉(zhuǎn)發(fā)轉(zhuǎn)播數(shù)據(jù)的主機就稱為轉(zhuǎn)發(fā)組播的主機，例如網(wǎng)絡(luò)路由器或三層交換機。轉(zhuǎn)發(fā)組播數(shù)據(jù)的代理服務(wù)器或CDN網(wǎng)絡(luò)邊緣服務(wù)器既可以稱之為發(fā)送組播數(shù)據(jù)的主機，也可以稱之為轉(zhuǎn)發(fā)組播數(shù)據(jù)的主機。
5.約定地址的補包主機補包主機是指在本發(fā)明中完成對接收數(shù)據(jù)的主機補包工作的主機，由于現(xiàn)行的組播協(xié)議沒有規(guī)定對于丟包如何處理，更沒有定義在哪里補包，所以在本發(fā)明中需要約定針對每個組播數(shù)據(jù)流的丟包要到哪里尋求補包數(shù)據(jù)。它可以約定是發(fā)送組播流的源服務(wù)器本身；可以約定是網(wǎng)絡(luò)中的路由器或交換機；可以約定是CDN的邊緣服務(wù)器，或是約定另外一臺客戶機；也不排除將來出現(xiàn)的某種新型硬件設(shè)備，只要它能完成響應(yīng)補包請求都可以成為補包主機。
約定地址，是指對上述客戶機、服務(wù)器和交換機可以固定約定或用某種規(guī)則約定用某些單播地址進行補包。由于客戶機要求發(fā)送組播流的服務(wù)器或轉(zhuǎn)發(fā)組播流的交換機路由器在原來的組播數(shù)據(jù)流當中對丟包錯包進行補包容易造成混亂且比較困難，所以在本發(fā)明中客戶機、服務(wù)器和交換機可以固定約定或用某種規(guī)則約定用某些單播地址進行補包。該地址約定包括但不限于可以約定用某個或某些單播地址對一個或一些組播地址補包；可以約定使用服務(wù)器和客戶機原有的單播地址，也可以另外約定補包地址；還可以在傳輸過程中根據(jù)負載臨時約定補包地址；也可以約定由另外一個正在接收此數(shù)據(jù)流或已經(jīng)接收到此數(shù)據(jù)的客戶機給自己補包，而此提供補包服務(wù)的客戶機的單播地址也就成為了補包地址。
為上述客戶機、服務(wù)器和交換機提供約定地址的方式主要包括但不僅限于以下幾種(1)在接收數(shù)據(jù)的主機內(nèi)部進行設(shè)置，在接收數(shù)據(jù)端約定固定的補包地址，或按固定規(guī)則約定的補包地址，如圖1a所示，一旦發(fā)現(xiàn)丟包，接收數(shù)據(jù)的主機直接尋找約定地址的補包主機請求補包。
(2)在動態(tài)訪問網(wǎng)絡(luò)的過程中從某負責指引的服務(wù)器動態(tài)地取得訪問補包主機的地址，在實際應(yīng)用中此指引服務(wù)器還可以同時指引組播地址，如圖1b所示，在后面敘述的利用CDN邊緣服務(wù)器補包的方式就可以使用這種補包方式。
(3)將以上兩種結(jié)合，即接收數(shù)據(jù)的主機先訪問固定或固定規(guī)則約定的地址的主機，從其獲得所需的補包主機的地址等相關(guān)指引信息，然后再根據(jù)指引找到補包主機進行補包；6.接收數(shù)據(jù)的主機是指用本發(fā)明方式中接收數(shù)據(jù)的主機，它主要指的是客戶機；網(wǎng)絡(luò)中的路由器和CDN邊緣服務(wù)器，如果既使用本發(fā)明方式接收數(shù)據(jù)又采用本發(fā)明的方式轉(zhuǎn)發(fā)數(shù)據(jù)，則其身份既是接收數(shù)據(jù)的主機又是轉(zhuǎn)發(fā)數(shù)據(jù)的主機；如果用網(wǎng)絡(luò)中的客戶機兼職完成向其他客戶機補包的工作，則其身份既是接收數(shù)據(jù)的主機又是補包主機。
7.客戶機是指處于使用數(shù)據(jù)的客戶一端的接收的計算機，是相對于專門提供服務(wù)的服務(wù)器計算機而言的?？蛻魴C主要包括但不僅限于臺式計算機、筆記本電腦、PDA、機頂盒等設(shè)備機頂盒因其放置于電視機的頂部而得名，但從技術(shù)角度講其本質(zhì)就是一臺比較簡單的計算機，但又與一般的計算機有所不同，其主要區(qū)別有兩點一是其顯示接口輸出不是一般的計算機顯示器而是電視機；二是操作輸入接口不是鍵盤鼠標而是遙控器。在本發(fā)明中機頂盒完全可以成為一臺客戶機。
8.定位標尺是指在本發(fā)明中為了使補包主機準確地知道接收數(shù)據(jù)的主機需要哪些數(shù)據(jù)，而采用的一種能夠定位和衡量數(shù)據(jù)的準確度量。該度量方式主要包括但不僅限于以下兩種方式，一種是基于數(shù)據(jù)的存儲方式，例如，以文件的起始點為原點，以存儲的長度或偏移量為單位度量其位置和長度。另一種是直接用數(shù)據(jù)包為標尺的度量單位，數(shù)據(jù)包的標號可以借用IP包頭中的序號，也可以由程序在數(shù)據(jù)包的內(nèi)部數(shù)據(jù)中進行編號。如果是采用數(shù)據(jù)包作為標尺刻度，則此刻度可能是不定長的，因為，根據(jù)需要服務(wù)器可能發(fā)送不定長的數(shù)據(jù)包，例如，許多流媒體的傳輸其數(shù)據(jù)包就是不定長的。
本發(fā)明提出的方法可以方便地解決組播協(xié)議傳輸數(shù)據(jù)的可靠性的問題，這一技術(shù)的推廣使用可以使組播協(xié)議可以廣泛應(yīng)用于網(wǎng)絡(luò)中傳輸各種數(shù)據(jù)，從根本上解決困擾寬帶網(wǎng)的“寬帶無內(nèi)容”問題。


圖1是本發(fā)明的數(shù)據(jù)傳輸過程示意圖，其中圖1a是在接收數(shù)據(jù)的主機內(nèi)設(shè)定了補包主機的地址的數(shù)據(jù)傳輸過程示意圖；圖1b是在動態(tài)訪問網(wǎng)絡(luò)的過程中從某負責指引的服務(wù)器動態(tài)地取得訪問補包主機地址的數(shù)據(jù)傳輸過程示意圖。
圖2是本發(fā)明的第一種實施例圖，其中發(fā)送組播的服務(wù)器和補包服務(wù)器是同一個物理服務(wù)器。
圖3是本發(fā)明的第二種實施例圖，其中補包服務(wù)器位于網(wǎng)絡(luò)邊緣，專門為某一區(qū)域的客戶機補包。
圖4是本發(fā)明的第三種實施例圖其中部分補包工作由客戶機完成，每個客戶機同時兼職為其他客戶機補包。
圖5是本發(fā)明中的第四種實施例圖，其中某一級或每一級路由器都可以發(fā)現(xiàn)丟包并向上一級請求補包。
圖6是本發(fā)明判斷丟包的簡化邏輯框圖。
圖7是本發(fā)明判斷丟包的智能邏輯框圖。
圖8是本發(fā)明接收數(shù)據(jù)主機的功能模塊圖。
具體實施例方式
以下結(jié)合附圖對本發(fā)明作進一步詳細描述。
本發(fā)明的方法如同電視系統(tǒng)一樣分為發(fā)送方式和接收方式，兩者可以分別構(gòu)成獨立的系統(tǒng)由不同的個體來分部實施，但為了便于描述和理解兩者的配合，將發(fā)送方和接收方兩者放到一起來描述其運作過程。
參照圖1a，本發(fā)明的數(shù)據(jù)傳輸過程為(1)由發(fā)送或轉(zhuǎn)發(fā)組播數(shù)據(jù)的主機向接收數(shù)據(jù)的主機發(fā)送至少一條組播數(shù)據(jù)流；(2)在接收數(shù)據(jù)的主機內(nèi)部中設(shè)定了補包主機的地址，接收組播數(shù)據(jù)流的數(shù)據(jù)，(3)接收數(shù)據(jù)的主機在接收組播數(shù)據(jù)流的過程中不斷監(jiān)測是否有錯包和丟包數(shù)據(jù)，在發(fā)現(xiàn)并接收到錯包和丟包的數(shù)據(jù)后，以單播協(xié)議向補包主機發(fā)出補包請求；(4)補包主機使用至少一個約定的單播地址，接收該補包請求，并按照該補包請求的定位標尺從存儲器中找到相應(yīng)的數(shù)據(jù)，以單播協(xié)議向請求補包的接收數(shù)據(jù)的主機發(fā)送補包數(shù)據(jù)；(5)接收數(shù)據(jù)的主機將接收到的有丟包的組播數(shù)據(jù)與單播補包數(shù)據(jù)整合，使之成為完整或部分完整的數(shù)據(jù)流。
參照圖1b，本發(fā)明的補包主機的地址是在動態(tài)訪問網(wǎng)絡(luò)的過程中，從某負責指引的服務(wù)器動態(tài)地取得訪問補包主機地址的數(shù)據(jù)，其數(shù)據(jù)傳輸過程為(1)由接收數(shù)據(jù)的主機向指引服務(wù)器請求指引；(2)指引服務(wù)器接收到指引請求后，向接收數(shù)據(jù)的主機發(fā)出指引信息；(3)接收數(shù)據(jù)的主機指引服務(wù)器發(fā)送的指引信息，請求加入組播并接收組播數(shù)據(jù)流；(4)接收數(shù)據(jù)的主機在接收組播數(shù)據(jù)流的過程中，按照圖6或圖7的過程不斷監(jiān)測是否有錯包和丟包數(shù)據(jù)，在發(fā)現(xiàn)并接收到錯包和丟包的數(shù)據(jù)后，以單播協(xié)議向補包主機發(fā)出補包請求；(5)補包主機使用至少一個約定的單播地址，接收該補包請求，并按照該補包請求的定位標尺從存儲器中找到相應(yīng)的數(shù)據(jù)，以單播協(xié)議向請求補包的接收數(shù)據(jù)的主機發(fā)送補包數(shù)據(jù)；(6)接收數(shù)據(jù)的主機將接收到的有丟包的組播數(shù)據(jù)與單播補包數(shù)據(jù)整合，使之成為完整或部分完整的數(shù)據(jù)流。
本方法主要用于傳輸流媒體，但由于其解決了傳輸?shù)目煽啃砸部梢杂脕韨鬏斊渌麛?shù)據(jù)。實現(xiàn)本發(fā)明的方法可以有多種變化形式，以下給出四種實施例，且叢最直接簡單的方式逐步描述其他提高的變化方式。
實施例1本發(fā)明的第一實施例是在數(shù)據(jù)網(wǎng)絡(luò)中實現(xiàn)數(shù)據(jù)傳輸?shù)幕痉椒?，如圖2所示。圖2中，包括一臺服務(wù)器、數(shù)臺客戶機和網(wǎng)絡(luò)，其中網(wǎng)絡(luò)包括數(shù)臺路由器和交換機。服務(wù)器A向數(shù)個組播地址分別發(fā)送數(shù)個組播數(shù)據(jù)流，客戶機A申請加入其中地址為224.2.2.1的組播，網(wǎng)絡(luò)路由器應(yīng)答客戶機發(fā)送的請求，向客戶機復(fù)制組播1中的數(shù)據(jù)流。在一般情況下如果在復(fù)制傳輸過程中出現(xiàn)丟包錯包是無法修復(fù)的，客戶機甚至難以發(fā)現(xiàn)丟包。在本方法中，客戶機或路由器采用特有方式發(fā)現(xiàn)丟包，如果發(fā)生丟包，客戶機將以單播協(xié)議向服務(wù)器發(fā)送請求數(shù)據(jù)包，請求服務(wù)器重發(fā)一個或幾個數(shù)據(jù)包。服務(wù)器按客戶機的請求以單播協(xié)議向客戶機發(fā)送一個或幾個數(shù)據(jù)包，以彌補組播丟包所喪失的數(shù)據(jù)。
接收數(shù)據(jù)的主機既可以采用像客戶機這樣的通用計算機的結(jié)構(gòu)；也可以是向路由器這樣的根據(jù)其專門功能專門設(shè)計的設(shè)備，甚至其中的模塊可以是特定應(yīng)用集成線路(ASCI)。但在本發(fā)明中他們必須具備這樣幾個模塊來完成其功能存儲模塊，用于存儲接收到的數(shù)據(jù)；組播接收模塊，用于接收組播數(shù)據(jù)；丟包判斷及補包控制模塊，用于判斷所收到的數(shù)據(jù)是否產(chǎn)生丟包，并控制單播收發(fā)模塊進行補包；單波收發(fā)模塊，用于以單播協(xié)議向補包服務(wù)器發(fā)送補包請求并接收補包服務(wù)器發(fā)來的補包數(shù)據(jù)。在專用設(shè)備中這些功能模塊可以是專門設(shè)計的模塊，在通用計算機結(jié)構(gòu)當中這些模塊是程序通過控制通用CPU、存儲器和數(shù)據(jù)傳輸接口來實現(xiàn)的，其中組播接收模塊是由程序通過CPU控制網(wǎng)卡來構(gòu)成的；存儲模塊是由程序通過CPU控制存儲器來構(gòu)成的；丟包判斷及補包控制模塊是由程序通過CPU控制存儲器來構(gòu)成的；單波收發(fā)模塊是由程序通過CPU控制網(wǎng)卡來構(gòu)成的；各功能模塊執(zhí)行接收數(shù)據(jù)的過程如圖8所示。組播接收模塊將接收到的數(shù)據(jù)存儲到存儲模塊當中；丟包判斷及補包控制模塊對所接收到的數(shù)據(jù)進行判斷，其中丟包判斷及補包控制模塊的具體操作過程可以是如圖6所示的簡捷的方式或圖7所示的智能方式，其主要功能是能根據(jù)數(shù)據(jù)包的序號判斷出丟包，能判斷出數(shù)據(jù)包序號的重計及在此情況下的丟包，進一步的智能功能是在上一級傳來的組播數(shù)據(jù)的數(shù)據(jù)包序號非正常排列的情況下也能準確判斷出丟包，如果丟包判斷及補包控制模塊發(fā)現(xiàn)丟包則使用標尺度量丟包的位置和長度，并利用這些信息控制單播收發(fā)模塊進行補包；單播收發(fā)模塊向約定地址的補包主機請求補包，并在收到補包數(shù)據(jù)后將其交給丟包判斷及補包控制模塊；丟包判斷及補包控制模塊根據(jù)丟包的記錄及標尺將補包數(shù)據(jù)與存于存儲模塊中的以組播協(xié)議收到的有丟包的數(shù)據(jù)進行整合，使之成為完整或是部分完整的數(shù)據(jù)。
這一過程看似比較簡單，在單播協(xié)議傳輸?shù)臄?shù)據(jù)流很容易實現(xiàn)補包，但對于組播傳輸?shù)臄?shù)據(jù)流實現(xiàn)補包需要解決一系列問題，這也就是為什么組播協(xié)議在實際使用中一直未能實現(xiàn)可靠傳輸?shù)脑颉?br> 本發(fā)明對于用組播傳輸?shù)臄?shù)據(jù)流實現(xiàn)補包所解決的關(guān)鍵技術(shù)如下(1)如何發(fā)現(xiàn)丟包？在單播TCP協(xié)議的傳輸過程中是通過ACK和NACK等復(fù)雜的往復(fù)應(yīng)答來實現(xiàn)發(fā)現(xiàn)丟包并補包的，但在目前的組播協(xié)議中并沒有這一過程，也很難實現(xiàn)這一過程，所以目前的組播協(xié)議本身是不能自動發(fā)現(xiàn)丟包的，客戶端程序或下一級路由器只是接收組播數(shù)據(jù)，但并不知道此數(shù)據(jù)是否完整。
為了解決這一問題，本發(fā)明采用在每個數(shù)據(jù)包中加入一個按升序或降續(xù)排列的序號信息，也可以考慮使用IP包頭中的包序號，根據(jù)數(shù)據(jù)包順序發(fā)現(xiàn)丟包，如圖6所示的簡化過程，當發(fā)現(xiàn)數(shù)據(jù)包的順序是2、3、6時，就認為4、5號數(shù)據(jù)包被丟失。但這樣在復(fù)雜的網(wǎng)絡(luò)環(huán)境中有可能將數(shù)據(jù)在傳輸過程中的意外導(dǎo)致的數(shù)據(jù)包順序混亂誤認為丟包，在此例中，有可能在2、3、6號數(shù)據(jù)包之后5、4、7、8號數(shù)據(jù)包就傳來了。所以可以作較為智能的判斷，如圖7所示智能過程，先將丟包計入丟包列表，等7、8號數(shù)據(jù)包甚至更多數(shù)據(jù)包傳來以后，還未發(fā)現(xiàn)4、5號數(shù)據(jù)包時，才判定4、5號數(shù)據(jù)包被丟失。該等待時間的判斷條件可以采用多種不同方式，在圖7中的推遲條件是從第一個丟包開始向后推遲4個數(shù)據(jù)包，在實際應(yīng)用中也可以從最后一個丟包開始計算推遲數(shù)個數(shù)據(jù)包，或其他更復(fù)雜的算法，這種智能判斷對于多級傳輸多級補包的復(fù)雜網(wǎng)絡(luò)來說是很重要的。
另外一個問題是數(shù)據(jù)包序號不是無限大的，所以存在一個問題就是當序號用盡時需要從頭開始使用序號，即數(shù)據(jù)包序號重新開始，這時有可能產(chǎn)生判斷的混亂，這時就需要復(fù)雜的條件判斷。例如如圖7所示假設(shè)最大數(shù)據(jù)包序號是65535，客戶端接到數(shù)據(jù)包的順序是65532、65533、3、4，發(fā)現(xiàn)后面的數(shù)據(jù)包序號小于前面的數(shù)據(jù)包，這時就需要請求補包服務(wù)器發(fā)送從65534到最大序號65535以及從最小序號0到2，共五個數(shù)據(jù)包的數(shù)據(jù)。
還有一種技術(shù)實現(xiàn)方式會將上述情況變得更加復(fù)雜，如在循環(huán)重復(fù)傳輸數(shù)據(jù)的方法中，可能一段數(shù)據(jù)長度較短，還不到最大序號的時候就到此段的末尾了，服務(wù)器需要從頭循環(huán)傳輸數(shù)據(jù)，此時如果不理會數(shù)據(jù)的結(jié)構(gòu)，序號繼續(xù)增加，則用上面的處理方法就可以解決。但如果考慮到數(shù)據(jù)的結(jié)構(gòu)，希望數(shù)據(jù)與序號有所對應(yīng)，則數(shù)據(jù)從頭開始再次循環(huán)時需要將數(shù)據(jù)包序號也從頭開始。在這種情況下客戶機需要預(yù)先知道此段循環(huán)傳輸數(shù)據(jù)的長度，并以此判斷。如果此段數(shù)據(jù)的長度較長，超出了序號范圍，則需要同時結(jié)合數(shù)據(jù)包序號和此段數(shù)據(jù)的長度進行綜合的判斷。
另有一種特殊情況就是網(wǎng)絡(luò)的第二層如果發(fā)現(xiàn)錯包可能會直接將其丟棄，Ethernet網(wǎng)的數(shù)據(jù)鏈路層會對每一個數(shù)據(jù)包進行CRC效驗，發(fā)現(xiàn)錯誤會將其丟棄，這種情況也被視為丟包。
(2)如何定位丟包？對丟包數(shù)據(jù)進行定位是本發(fā)明方法需要解決的重要問題。在單播協(xié)議中，數(shù)據(jù)包在服務(wù)器和路由器當中以數(shù)據(jù)包的形式緩存部分剛發(fā)送過的數(shù)據(jù)，任何一級發(fā)現(xiàn)丟包都可以立刻向上一級要求補包，這是TCP/IP協(xié)議棧中已經(jīng)定義的功能，這些功能都是網(wǎng)絡(luò)中的路由器和計算機的底層IP協(xié)議棧自動來完成的。但是在本實施例中補包功能需要由客戶機和服務(wù)器的軟件功能來實現(xiàn)，這就存在一個定位的問題，即對于傳輸?shù)臄?shù)據(jù)需要有一種標尺的機制對其進行定位和度量，以保證服務(wù)器發(fā)給客戶機的補包數(shù)據(jù)是其需要補充的，并將其與原數(shù)據(jù)整合。
一種度量方式是基于數(shù)據(jù)的存儲方式，例如，以文件的起始點為原點，以存儲的長度或偏移量為單位度量其位置和長度。
另一種度量方式是直接用數(shù)據(jù)包定位，即由服務(wù)器的程序控制一塊緩沖區(qū)，這塊緩沖區(qū)可以在硬盤上，也可以在內(nèi)存中，在緩沖區(qū)中，數(shù)據(jù)的存儲方式是以將要發(fā)送的數(shù)據(jù)包的形式來存儲的。例如，發(fā)送組播的時候是以每1k字節(jié)內(nèi)容為一個數(shù)據(jù)包的，則存儲方式就是以1k字節(jié)為一個存儲單元，并配合排列序號，則每個數(shù)據(jù)包的存儲單元就是度量標尺的一個刻度。此存儲單元也可以是不定長的，例如，以流媒體的一幀或幾幀作為存儲單元和度量標尺，其表尺的刻度就是不定長的。但這并不影響標尺的使用，因為這個標尺并不是用來度量數(shù)據(jù)的絕對長度，而是用來定位丟包和補包數(shù)據(jù)的，所以只要他能正確的找到補包數(shù)據(jù)就可以了。
(3)何時請求補包？
客戶機發(fā)現(xiàn)丟包后可以立刻請求補包，也可以等一段時間，將在此時間段中發(fā)現(xiàn)的所有丟包一并請求補包。第一種方式適合用于對數(shù)據(jù)的及時性要求較高的情況，例如IPTV、VOD等；第二種方式適合用于對數(shù)據(jù)的及時性要求較低的情況例如下載。
(4)向誰請求補包？在現(xiàn)有的單播系統(tǒng)中，可以直接向上一級的路由器或三層交換機請求補包，上一級路由器或交換機將丟包重傳，但現(xiàn)有的組播協(xié)議無法完成這樣的過程。為了實現(xiàn)數(shù)據(jù)的可靠傳輸，在本實施例中可以由發(fā)送組播數(shù)據(jù)流的源服務(wù)器完成補包工作。在客戶端發(fā)現(xiàn)丟包后立刻向源服務(wù)器發(fā)送一個請求，此請求描述所丟數(shù)據(jù)包的序號，或直接根據(jù)數(shù)據(jù)的度量表尺對丟失的數(shù)據(jù)進行描述，從而使服務(wù)器知道哪臺客戶機缺少那些數(shù)據(jù)。
在現(xiàn)有的1P組播協(xié)議當中，服務(wù)器發(fā)送組播的網(wǎng)卡必定有一個單播地址，而且其發(fā)送的組播數(shù)據(jù)包中攜帶此單播地址，可以約定客戶機使用此單播地址作為目標地址直接向補包服務(wù)器發(fā)送補包請求，當然也可以另外約定一個地址，甚至是另外一個主機的地址。
(5)如何識別補包請求？在一般情況下，服務(wù)器的一塊網(wǎng)卡可以分別向多個組播地址發(fā)送多個組播數(shù)據(jù)流，而在本發(fā)明中客戶機請求補包并不是向發(fā)生了丟包的組播數(shù)據(jù)流的組播地址發(fā)送，而是向一個單播地址發(fā)送補包請求，簡單的方法是每一個組播地址對應(yīng)一個單播補包地址，但這樣的方式要消耗很多單播地址。比較劃算的方式是多個組播地址對應(yīng)一個單播地址，這樣就存在一個如何識別客戶機到底是需要補的是哪一個組播數(shù)據(jù)流的數(shù)據(jù)，在實際應(yīng)用當中可以考慮約定服務(wù)器發(fā)送組播數(shù)據(jù)流時使用不同的端口號，服務(wù)器補包服務(wù)也是約定用單播地址的不同端口，這些端口與組播數(shù)據(jù)流的端口一一對應(yīng)，服務(wù)器就可以識別客戶需要補包的數(shù)據(jù)流了。例如服務(wù)器發(fā)送三個組播數(shù)據(jù)流，地址分別是224.2.2.14001、224.2.2.24002、224.2.2.34003，服務(wù)器網(wǎng)卡的單播地址是192.168.2.2，這樣就可以“約定”凡是客戶機在接收組播地址224.2.2.34003的數(shù)據(jù)流的過程中發(fā)現(xiàn)的丟包，一律向服務(wù)器的單播地址192.168.2.2∶4003發(fā)送補包請求。而服務(wù)器根據(jù)約定，一旦從4003號端口收到補包請求，就理解為客戶機需要對224.2.2.3的數(shù)據(jù)流進行補包。
另外一種更安全的方式是客戶機的補包請求中直接按照某種格式描述要補某個組播地址的數(shù)據(jù)流的某幾個數(shù)據(jù)包，這樣服務(wù)器不用開多個端口對應(yīng)多個組播地址，其優(yōu)點是服務(wù)器所開的端口少，從而使服務(wù)器更安全。
(6)如何發(fā)送補包？服務(wù)器響應(yīng)客戶機請求向其發(fā)送補包可以直接根據(jù)客戶機請求補包的數(shù)據(jù)包的源地址向其發(fā)送補包數(shù)據(jù)。當然如果客戶機具有多個單播地址，并且其要求服務(wù)器向客戶機的另一個地址發(fā)送補包數(shù)據(jù)，也可以按其要求發(fā)送。
(7)如何應(yīng)對大量丟包的情況？在網(wǎng)絡(luò)中可能會存在個別線路狀況極差的情況，其接收端有可能發(fā)現(xiàn)丟失大量的數(shù)據(jù)包需要重發(fā)，這樣可能會對發(fā)送補包數(shù)據(jù)的一端產(chǎn)生極大的壓力。對于這種狀況數(shù)據(jù)發(fā)送端可以對于這樣的接收端拒絕服務(wù)；也可以在接收端的軟件中設(shè)置一個極限值，如果丟包率超過某一值便不再請求補包。
通過采用以上技術(shù)關(guān)鍵，就可以在現(xiàn)行的網(wǎng)絡(luò)環(huán)境和組播協(xié)議的條件下順利地實現(xiàn)對組播數(shù)據(jù)流進行補包，實現(xiàn)數(shù)據(jù)的可靠傳輸。但是如果只用上述的基本方式，在大規(guī)模網(wǎng)絡(luò)的環(huán)境下還不夠完美，處理效率還不夠高，所以還可以采用或綜合運用如下幾種改進方式來提高效率。
由于在本發(fā)明當中規(guī)定對組播數(shù)據(jù)進行補包，所以對于服務(wù)器的內(nèi)存緩沖可以進行與一般組播方式不同的處理來提高補包的效率和速度。現(xiàn)行的組播協(xié)議由于不存在補包，所以現(xiàn)行的程序和操作系統(tǒng)將發(fā)送過的組播數(shù)據(jù)立即將其清除出內(nèi)存緩沖區(qū)。
在本發(fā)明中，服務(wù)器可以建立一個共用的快速存儲器緩沖區(qū)，在目前的技術(shù)條件下，快速存儲器主要是指內(nèi)存RAM，主要包括DDR RAM、ECC RAM等，將來可能會有更好的快速存儲器而且可以在網(wǎng)卡上建立專門的存儲硬件用于緩沖，在本實施例中，為了便于理解我們暫時仍然稱其為內(nèi)存緩沖或緩沖區(qū)。通常的組播程序?qū)⒁粋€組播數(shù)據(jù)包發(fā)送出去以后立即將其清除，但在本發(fā)明中此共用的內(nèi)存緩沖區(qū)既用于發(fā)送組播流也用于單播補包，所以此內(nèi)存緩沖區(qū)中的數(shù)據(jù)在通過組播發(fā)送出去以后并不立即清除，而是在內(nèi)存緩沖區(qū)保持一段時間，如果在此期間客戶機請求補包，服務(wù)器立刻從內(nèi)存緩沖當中讀取相應(yīng)的數(shù)據(jù)并以單播形式發(fā)送給發(fā)請求的客戶機。
有一種情況可能導(dǎo)致緩沖區(qū)補包失敗，由于緩存不可能無限大，需要不斷用新數(shù)據(jù)替代舊數(shù)據(jù)，所以當發(fā)生一長段連續(xù)丟包時，有可能會出現(xiàn)的一種特殊情況，就是接收數(shù)據(jù)的主機發(fā)送的補包請求到達服務(wù)器時，這一長段丟包數(shù)據(jù)的前面部分已經(jīng)被新數(shù)據(jù)更新了，解決方式包括但不僅限于以下兩種方式1.在服務(wù)器端進行判斷，當出現(xiàn)這種超長補包請求時，對于其中的全部或部分數(shù)據(jù)定向到慢速存儲器既硬盤中讀取
2.當組播數(shù)據(jù)流是比較穩(wěn)定帶寬的碼流時可以在接收數(shù)據(jù)的主機一端進行丟包推測，例如正常情況下每100毫秒會傳來10個數(shù)據(jù)包，但發(fā)現(xiàn)已經(jīng)連續(xù)200毫秒沒有收到數(shù)據(jù)包了，這時雖然后續(xù)數(shù)據(jù)包沒有傳來無法斷定丟包，但可以推測發(fā)生丟包了，接收數(shù)據(jù)的主機就可以認為是發(fā)現(xiàn)丟包并請求補包。這樣可以避免當后續(xù)數(shù)據(jù)包傳來、可以判定丟包時，實際上已經(jīng)丟失了大量的數(shù)據(jù)包的情況發(fā)生。
這種改進方式的優(yōu)點是提高了補包的效率，同時也提高了服務(wù)器的補包能力?，F(xiàn)行的流媒體服務(wù)器系統(tǒng)的瓶頸在于其磁盤或磁盤陣列的讀取速度，而CPU處理能力和內(nèi)存空間往往有富裕，所以通過這一改進減少了磁盤的負擔，提高了服務(wù)器的整體能力，使得一個服務(wù)器或服務(wù)器群組能夠至少為一個目前的寬帶城域網(wǎng)提供補包服務(wù)，保障城域網(wǎng)范圍內(nèi)利用組播傳輸可靠數(shù)據(jù)。
實施例2本發(fā)明的第二實施例是對上述實施例1的改進，如圖3所示。由于在客戶數(shù)量巨大的網(wǎng)絡(luò)環(huán)境下，用單播協(xié)議的補包服務(wù)器的負載往往是很重的，在此例中雖然單播只是用于補包，而絕大部分數(shù)據(jù)流都是由組播傳輸?shù)模@也是一個巨大的負載，特別是當網(wǎng)絡(luò)環(huán)境比較差丟包比較嚴重的時候。為了解決這個問題可以讓補包服務(wù)專門由一個或幾個服務(wù)器來完成，這幾臺服務(wù)器甚至可以分布在網(wǎng)絡(luò)的不同位置。單播補包服務(wù)器的布放位置可以借鑒現(xiàn)在常用的CDN(Content distribution network或Content deliverynetwork的縮寫)和任播的方式，將補包的負載分散到網(wǎng)絡(luò)的邊緣，由那些較靠近客戶機的服務(wù)器完成，其優(yōu)點是補包反應(yīng)快，對網(wǎng)絡(luò)主干的壓力小。這種方式就需要改進客戶機和網(wǎng)絡(luò)的尋找、定位補包服務(wù)器的方式。
一種方式是任播方式，客戶機還是按照組播源服務(wù)器的單播地址尋求補包，但是由網(wǎng)絡(luò)設(shè)備自動將某一區(qū)域的請求重定位到另一個距離客戶較近的服務(wù)器，“約定”哪些區(qū)域的請求重定位發(fā)送到哪個服務(wù)器是在網(wǎng)絡(luò)設(shè)備當中進行設(shè)置的。
另一種方式是直接讓客戶機向另外一個“約定地址”的服務(wù)器尋求補包服務(wù)，可以用多種技術(shù)來實現(xiàn)這種方式，可以規(guī)定客戶機的程序必須先向主服務(wù)器詢問可以向哪一個或那些服務(wù)器尋求補包，服務(wù)器可以根據(jù)客戶機的地址所屬區(qū)域指示其向哪一個或那些服務(wù)器尋求補包，或者給客戶機發(fā)送一個列表，由客戶機自主判斷向哪一個或那些服務(wù)器尋求補包；也可以在客戶機與源服務(wù)器建立連接或要求補包時服務(wù)器指示客戶機到某個約定的服務(wù)器補包；還可以借鑒DNS的方式，在每個區(qū)域設(shè)置一個指示服務(wù)器，各地區(qū)的客戶機軟件都需要手工或自動設(shè)置本地區(qū)指引務(wù)器的地址，向此服務(wù)器要求補包或詢問可以向哪一個或哪些服務(wù)器尋求補包。
在這種方式中，在物理上是多臺服務(wù)器組成一個服務(wù)器群組共同協(xié)作完成組播的發(fā)送和補包，但可以在邏輯上將他們視為一個服務(wù)器。
實施例3本發(fā)明的第三實施例是對實施1的另一種改進，如圖4所示。本例是在補包方式上借鑒P2P的方式，現(xiàn)行的P2P傳輸?shù)姆绞绞菍⑺械男畔⒍加煽蛻魴C之間相互傳輸，服務(wù)器只提供一些指引，例如BT。這樣做的結(jié)果就是每個客戶機都要向一個或多個客戶服務(wù)，有時向別人提供服務(wù)的帶寬比自己接收數(shù)據(jù)的帶寬還要大，這對網(wǎng)絡(luò)主干和客戶機來說負載太大。在本發(fā)明的此改進方式中，主要數(shù)據(jù)還是通過服務(wù)器發(fā)送的組播來傳輸?shù)?，只有部分缺失的?shù)據(jù)才通過客戶機之間的相互服務(wù)來補充。要實現(xiàn)這種方式，需要在服務(wù)器中維護一個列表，此列表表明哪些客戶機正在或已經(jīng)接收過哪些組播數(shù)據(jù)，當一個客戶機開始接收某個組播時通知服務(wù)器，服務(wù)器將幾個同樣接收此組播數(shù)據(jù)的客戶機“伙伴”的單播地址通告此客戶機，同時也會將它作為一個伙伴記錄通知其他伙伴。當此客戶機發(fā)現(xiàn)丟包或數(shù)據(jù)缺失時可以向其“伙伴”請求補充數(shù)據(jù)，由另一個或幾個作為其伙伴的客戶機向其發(fā)送缺失的數(shù)據(jù)，也就是說由另一臺客戶機兼職完成原本應(yīng)由補包服務(wù)器來完成的工作。同樣的，此客戶機也能向其他客戶機提供補包服務(wù)。
在此方式中，如果是網(wǎng)絡(luò)的核心交換機丟包，將會導(dǎo)致大面積的的客戶丟失相同的數(shù)據(jù)包，客戶機將難以相互補包。但是在實際網(wǎng)絡(luò)環(huán)境當中，網(wǎng)絡(luò)主干的服務(wù)質(zhì)量比較容易保障，網(wǎng)絡(luò)的客戶接入端特別是“最后一公里”的服務(wù)質(zhì)量難以保障，所以此方式在實際環(huán)境當中還是有實用價值的。對于個別的大面積客戶丟失相同數(shù)據(jù)包的情況可以用服務(wù)器或網(wǎng)絡(luò)交換機另行補包。
在這種方式中，在物理上是服務(wù)器和多臺客戶機組成一個服務(wù)器群組共同協(xié)作完成組播的發(fā)送和補包，但可以在邏輯上將客戶機中兼職為別人服務(wù)的那部分視為服務(wù)器的一部分。
實施例4本發(fā)明的第四實施例是對上述實施例1、實施例2、實施例3的改進。由于以上幾種實施例的方式無論是用服務(wù)器還是用客戶機兼職，都是用計算機進行補包的，這種補包方式容易實施，但靠計算機的軟件來實現(xiàn)的結(jié)果就是效率比較低，而且反應(yīng)速度都比較慢。在單播TCP協(xié)議中，補包的工作是由上一級的路由器來實現(xiàn)的，其處理效率和反應(yīng)速度都很快。所以可以考慮將補包的工作交由路由器或三層交換機來實現(xiàn)，如圖5所示。此方式可以在多級路由的大型網(wǎng)絡(luò)中實現(xiàn)類似單播協(xié)議的逐級補包，但如果要路由器或三層交換機來實現(xiàn)此功能，需要對其內(nèi)置軟件、操作系統(tǒng)甚至是硬件作較大的改動。
較為簡單的實現(xiàn)方式是直接將上述的由服務(wù)器完成的工作交由路由器來實現(xiàn)，但這就要求路由器不僅具有OSI七層協(xié)議的三層以內(nèi)的功能，還必須具有第四層甚至更高層的功能，因為它不僅需要查看IP包頭的信息還必須打開IP數(shù)據(jù)包，查看其中的內(nèi)容才能得知客戶機的丟包情況，幸好現(xiàn)在的技術(shù)實現(xiàn)四層交換，甚至更高層的功能并不困難。
比較復(fù)雜但處理效率更高的處理方法是直接在IP包頭中體現(xiàn)客戶機的補包要求，這需要對現(xiàn)有的1P協(xié)議棧進行一定的修改，首先在IP數(shù)據(jù)包頭中要有標志位表示客戶機的此數(shù)據(jù)包是一個請求補包的請求數(shù)據(jù)包，路由器通過此標志位區(qū)分補包請求和其他信息數(shù)據(jù)包，然后路由器就可以將此信息提出來另做處理了，至于客戶機或下一級路由器需要針對哪一個組播流進行補包、需要補多少則可以在包頭中描述也可以在數(shù)據(jù)包內(nèi)進行描述。對于客戶機需要對哪一個組播流進行補包還可以采用前面所述的用端口號對應(yīng)的方式來識別。
如果每一級路由器能用此改進方式所述傳輸組播，在網(wǎng)絡(luò)中就可以實現(xiàn)逐級補包，在網(wǎng)絡(luò)中的每一級路由器都實行對組播的可靠傳輸，而不是像前三種改進方式那樣需要組播數(shù)據(jù)一直傳到接收數(shù)據(jù)的客戶端以后才能發(fā)現(xiàn)丟包。但在這種方式中，每一臺路由器既是接收數(shù)據(jù)的主機又是發(fā)送數(shù)據(jù)的主機，這就涉及到它如何處理已經(jīng)收到的組播和補包數(shù)據(jù)并向下一級主機傳輸。該傳輸包括但不局限于以下方式1.將那些用單播協(xié)議補到的數(shù)據(jù)包重新加入到組播數(shù)據(jù)流中向下一級主機復(fù)制轉(zhuǎn)發(fā)。但這樣有可能會打亂原來的數(shù)據(jù)包順序，無論下一級主機是客戶機還是另一臺路由器，混亂的數(shù)據(jù)包順序都會對下一級主機的丟包判斷和補包造成困擾。對于這樣的情況可以有兩種處理方式a.不管數(shù)據(jù)包的順序，將補到的數(shù)據(jù)包不顧其原有順序直接整合到原來的組播數(shù)據(jù)流當中向下一級傳輸，由于上一級的補包需要一個時間過程，這樣在本級主機發(fā)向下一級主機的組播數(shù)據(jù)流中通過補包補回來的數(shù)據(jù)包就會落后于正常的數(shù)據(jù)包順序，下一級主機有可能在此落后于正常順序的數(shù)據(jù)包還未到達時就誤判此數(shù)據(jù)包丟失。這樣就需要各級主機對于丟包的判斷采用較為靈活智能的方式，例如，像前面“如何發(fā)現(xiàn)丟包”所述的那樣。
b.每一級主機收到組播后并不立即復(fù)制轉(zhuǎn)發(fā)，而是等待一定時間，這段時間足夠本主機發(fā)現(xiàn)丟保、請求補包、并得到上一級主機的補包，將補到的數(shù)據(jù)包按原有順序整合到原來的組播數(shù)據(jù)流當中向下一級傳輸。
2.本級主機將那些用單播協(xié)議從上一級主機補到的數(shù)據(jù)包放到緩存中，而不將其補充到原來的組播數(shù)據(jù)流中，但是其面臨的一個問題就是其下一級主機也會發(fā)現(xiàn)這些數(shù)據(jù)包丟失了，當然也會發(fā)現(xiàn)一些在本級主機向下一級傳輸中新增的丟包，這時本級主機可以對于這兩種情況的丟包都用單播協(xié)議對下一級主機進行補包。
通過運用上述的幾種方式就可以在一個中小規(guī)模的城域網(wǎng)范圍內(nèi)利用組播向大量用戶提供可靠的數(shù)據(jù)，如果再綜合運用基本方式和幾種改進方式，就有條件在幾乎整個Internet上全網(wǎng)運用組播協(xié)議傳輸可靠數(shù)據(jù)。
本發(fā)明的效果可以通過仿真測試予以證明。
仿真環(huán)境1網(wǎng)絡(luò)環(huán)境是華為的S3526三層交換機和S2026Z二層交換機，測試期間有其他正常的單播網(wǎng)絡(luò)通訊，服務(wù)器為P4 2.8G/1G RAM，客戶機為P3 1G/256 RAM筆記本。
本仿真作出了在兩組不同環(huán)境下的傳輸效果測試統(tǒng)計，其中第一組是在正常校園網(wǎng)環(huán)境下的傳輸效果統(tǒng)計，如表1所示。第二組是專門使用很差但單播能Ping通的網(wǎng)線模擬惡劣環(huán)境下的傳輸效果統(tǒng)計，如表2所示。
表1正常校園網(wǎng)環(huán)境下傳輸效果統(tǒng)計表

表2模擬惡劣的實際環(huán)境下傳輸效果統(tǒng)計表

說明在表1、2中的6M碼流時，組播丟包率驟升及補包率未能達到100％是因為客戶機的配置較低。
仿真環(huán)境2網(wǎng)絡(luò)環(huán)境港灣的BIG HAMMER6808三層交換機和Hammer24E二層交換機，測試期間有其他正常的單播網(wǎng)絡(luò)通訊，服務(wù)器為P4 2.8G/1G RAM，客戶機為P4 2.8G/256 RAM臺式機。
本仿真也作出了在兩組不同環(huán)境下的傳輸效果測試統(tǒng)計，其中第一組是在正常校園網(wǎng)環(huán)境下的傳輸效果統(tǒng)計，如表3所示。第二組是專門使用很差但單播能Ping通的網(wǎng)線模擬惡劣環(huán)境下的傳輸效果統(tǒng)計，如表4所示。
表3正常校園網(wǎng)環(huán)境下傳輸效果統(tǒng)計表

表4模擬惡劣的實際環(huán)境下傳輸效果統(tǒng)計表

從上述表1、表2、表3、表4的幾組測試數(shù)據(jù)可得出以下結(jié)論1.網(wǎng)絡(luò)環(huán)境惡劣會導(dǎo)致組播丟包率上升。
2.網(wǎng)絡(luò)環(huán)境惡劣不會導(dǎo)致單播補包成功率下降，幾乎對單播補包毫無影響。
3.本方法對于組播丟包的識別和補包率幾乎達到100％。
4.在大流量的情況下，客戶機性能對補包成功率有影響。
5.補包服務(wù)器負載很低，一臺服務(wù)器可以輕易承擔向數(shù)萬臺客戶機補包的工作。
權(quán)利要求
1.一種用組播和單播協(xié)議可靠傳送數(shù)據(jù)的方法，采用單播協(xié)議對組播數(shù)據(jù)流的丟包進行補包，其過程如下(1)由發(fā)送或轉(zhuǎn)發(fā)組播數(shù)據(jù)的主機發(fā)送至少一條組播數(shù)據(jù)流；(2)約定地址的補包主機使用至少一個約定的單播地址接收來自接收數(shù)據(jù)的主機的補包請求；(3)約定地址的補包主機接收并識別補包請求，并按照請求的定位標尺從存儲器中找到相應(yīng)的數(shù)據(jù)；(4)約定地址的補包主機找到相應(yīng)的數(shù)據(jù)后，以單播協(xié)議向請求補包的接收數(shù)據(jù)的主機發(fā)送補包數(shù)據(jù)。
2.一種用于對應(yīng)權(quán)利要求1的接收數(shù)據(jù)方法，其過程如下(1)接收數(shù)據(jù)的主機加入至少一個組播組，接收組播數(shù)據(jù)流的數(shù)據(jù)；(2)接收數(shù)據(jù)的主機在接收組播數(shù)據(jù)流的過程中，不斷監(jiān)測是否有錯包和丟包數(shù)據(jù)；(3)接收數(shù)據(jù)的主機發(fā)現(xiàn)錯包和丟包后，以單播協(xié)議向約定地址的補包主機發(fā)出補包請求；(4)接收數(shù)據(jù)的主機將接收到的有丟包的組播數(shù)據(jù)與單播補包數(shù)據(jù)進行整合，使其成為完整或部分完整的數(shù)據(jù)。
3.一種實現(xiàn)用組播和單播協(xié)議可靠接收數(shù)據(jù)的接收主機，包括存儲模塊，用于存儲接收到的數(shù)據(jù)；組播接收模塊，用于接收組播數(shù)據(jù)流的數(shù)據(jù)和以組播協(xié)議收到的有丟包的數(shù)據(jù)，并將接收到的這些數(shù)據(jù)存儲到存儲模塊中；丟包判斷及補包控制模塊，用于判斷所收到的組播數(shù)據(jù)流的數(shù)據(jù)是否產(chǎn)生丟包，并控制單播收發(fā)模塊進行補包；單波收發(fā)模塊，用于以單播協(xié)議向補包服務(wù)器發(fā)送補包請求，并接收補包服務(wù)器發(fā)來的補包數(shù)據(jù)；再將收到的補包數(shù)據(jù)交給丟包判斷及補包控制模塊與存儲模塊中的丟包數(shù)據(jù)進行整合。
4.根據(jù)權(quán)利要求1所述的傳送數(shù)據(jù)的方法，其中所述的約定地址的補包主機，可以約定是發(fā)送組播流的源服務(wù)器本身；或是網(wǎng)絡(luò)中的路由器或交換機；或是CDN的邊緣服務(wù)器；或是另外一臺客戶機；或是能完成響應(yīng)補包請求的其他主機；該約定地址可以約定用某個或某些單比地址對一個或一些單播地址補包；可以約定服務(wù)器和客戶機原有的單播地址，也可以另外約定補包地址；還可以在傳輸過程中根據(jù)負載臨時約定補包地址；也可以約定由另外一個正在接收此數(shù)據(jù)流或已經(jīng)接收到此數(shù)據(jù)的客戶機給自己補包，該提供補包服務(wù)的客戶機的單播地址也為補包地址；實現(xiàn)該約定地址的方式可選擇以下幾種a.在客戶機內(nèi)部進行設(shè)置，即在接收數(shù)據(jù)端約定固定的補包地址，或按固定規(guī)則約定補包地址；b.在動態(tài)訪問網(wǎng)絡(luò)的過程中從某負責指引的服務(wù)器動態(tài)地取得訪問補包主機的地址；c.將該兩者結(jié)合，接收數(shù)據(jù)的主機先訪問固定或固定規(guī)則約定的地址的主機，獲得所需的補包主機的地址等相關(guān)指引信息，再根據(jù)指引找到補包主機進行補包。
5.根據(jù)權(quán)利要求2所述的接收數(shù)據(jù)的方法，其中所述的接收數(shù)據(jù)的主機可以是網(wǎng)絡(luò)中的客戶機；或是網(wǎng)絡(luò)中的路由器；或是專門用于補包的約定地址的補包主機，該補包主機將接收到的數(shù)據(jù)用于向其他客戶機提供補包數(shù)據(jù)。
6.根據(jù)權(quán)利要求1所述的數(shù)據(jù)傳輸方法，其中所述的定位標尺主要有兩種度量方式一種是基于數(shù)據(jù)的存儲方式，即以文件的起始點為原點，以存儲的長度或偏移量為單位度量其位置和長度；另一種是直接用數(shù)據(jù)包作為標尺的度量單位，即將每個數(shù)據(jù)包的存儲單元作為度量標尺的一個刻度，數(shù)據(jù)包的標號可以借用IP包頭中的序號，也可以由程序在數(shù)據(jù)包的內(nèi)部數(shù)據(jù)中進行編號。
7.根據(jù)權(quán)利要求2或5或6所述的接收數(shù)據(jù)的方法，其中所述的接收數(shù)據(jù)的主機在接收組播數(shù)據(jù)流的過程中不斷監(jiān)測是否有錯包和丟包數(shù)據(jù)，其監(jiān)測方式有如下幾種(1)接收數(shù)據(jù)的主機不斷監(jiān)測位于數(shù)據(jù)包頭或數(shù)據(jù)包中的數(shù)據(jù)包序號，按數(shù)據(jù)包順序判斷是否丟包，一但發(fā)現(xiàn)丟包立刻請求補包；(2)接收數(shù)據(jù)的主機不斷監(jiān)測位于數(shù)據(jù)包頭或數(shù)據(jù)包中的數(shù)據(jù)包序號，按數(shù)據(jù)包順序判斷是否丟包，一但發(fā)現(xiàn)丟包立刻計入丟包列表，按照某種延遲規(guī)則等待后再請求補包，在延遲等待過程中不斷監(jiān)測后續(xù)傳來的數(shù)據(jù)包，如果發(fā)現(xiàn)有丟包列表中記錄的數(shù)據(jù)包，則將此記錄刪除。
8.根據(jù)權(quán)利要求1所述的數(shù)據(jù)傳輸方法，其中所述的約定地址的補包主機對所接收的補包請求的識別，是通過約定服務(wù)器發(fā)送組播數(shù)據(jù)流時使用不同的端口號，與補包服務(wù)器約定用單播地址使用不同地址或端口的對應(yīng)關(guān)系，識別客戶需要補包的數(shù)據(jù)流；或直接從數(shù)據(jù)包的內(nèi)容當中識別補包請求是針對哪一個組播數(shù)據(jù)流的。
9.根據(jù)權(quán)利要求1或4所述的數(shù)據(jù)傳送方法，其中所述的發(fā)送或轉(zhuǎn)發(fā)組播數(shù)據(jù)的主機與約定地址的補包主機使用同一臺服務(wù)器，該服務(wù)器中建立了共用快速存儲器緩沖區(qū)，從該共用快速存儲器緩沖區(qū)中取得數(shù)據(jù)，可分別用于發(fā)送組播和向請求補包的客戶機發(fā)送補包數(shù)據(jù)。
10.根據(jù)權(quán)利要求1或4所述數(shù)據(jù)傳送方法，其中所述的約定地址的補包主機使用一臺客戶機兼職完成所述的補包任務(wù)，且需要在發(fā)送組波數(shù)據(jù)服務(wù)器中維護一個列表，該列表記載有客戶機正在或已經(jīng)接收過的組播數(shù)據(jù)，當一個客戶機開始接收某個組播時通知服務(wù)器，服務(wù)器將一個或幾個正接收或已經(jīng)接收過相同組播數(shù)據(jù)的客戶機“伙伴”的單播地址通告此客戶機，并將它作為一個伙伴記錄通知其他伙伴，當此客戶機發(fā)現(xiàn)丟包或數(shù)據(jù)缺失時可以向其“伙伴”請求補充數(shù)據(jù)，由另一個或幾個作為其伙伴的客戶機向其發(fā)送缺失的數(shù)據(jù)。
11.根據(jù)權(quán)利要求1或4所述數(shù)據(jù)傳送方法，其中所述的約定地址的補包主機使用網(wǎng)絡(luò)中的路由器完成所述的補包任務(wù)，且將那些用單播協(xié)議補到的數(shù)據(jù)包，重新加入到組播數(shù)據(jù)流中向下一級主機復(fù)制轉(zhuǎn)發(fā)；或?qū)⒛切┯脝尾f(xié)議補到的數(shù)據(jù)包放到緩存中，由路由器用單播協(xié)議向下一級主機進行補包。
全文摘要
本發(fā)明公開了一種綜合運用組播和單播協(xié)議可靠傳輸數(shù)據(jù)的方法。其傳輸過程是由發(fā)送或轉(zhuǎn)發(fā)組播數(shù)據(jù)的主機向接收數(shù)據(jù)的主機發(fā)送至少一條組播數(shù)據(jù)流；接收數(shù)據(jù)的主機在接收組播數(shù)據(jù)流的過程中不斷監(jiān)測是否有錯包和丟包數(shù)據(jù)，并在發(fā)現(xiàn)并接收到錯包和丟包的數(shù)據(jù)后，以單播協(xié)議向約定地址的補包主機發(fā)出補包請求；約定地址的補包主機使用至少一個約定的單播地址接收該補包請求，并以單播協(xié)議向請求補包的接收數(shù)據(jù)的主機發(fā)送補包數(shù)據(jù)；接收數(shù)據(jù)的主機將接收到的有丟包的組播數(shù)據(jù)與單播補包數(shù)據(jù)整合，使其成為完整或部分完整的數(shù)據(jù)流。本發(fā)明解決了數(shù)據(jù)網(wǎng)絡(luò)中組播協(xié)議傳輸數(shù)據(jù)可靠性差的問題，適用于所有具有單播和組播通訊模式的網(wǎng)絡(luò)和網(wǎng)絡(luò)協(xié)議。
文檔編號H04L1/16GK1697354SQ200510042830
公開日2005年11月16日 申請日期2005年6月17日 優(yōu)先權(quán)日2005年6月17日
發(fā)明者顧紅波 申請人:顧紅波