[發(fā)明專利]網(wǎng)絡(luò)多播的數(shù)據(jù)包重接收處理方法

有效

• 申請?zhí)枺?/td>: 200810175582.1
• 申請日: 2008-11-07
• 公開（公告）號: CN101741586A
• 公開（公告）日: 2010-06-16
• 發(fā)明（設(shè)計）人: 李連成;吳樹桂;張陽;呂健;劉曉鵬;陳玄同
• 申請（專利權(quán)）人: 英業(yè)達(dá)股份有限公司
• 主分類號: H04L12/18
• 分類號: H04L12/18;H04L1/18;H04L1/00;H04L29/06
• 代理公司: 北京律誠同業(yè)知識產(chǎn)權(quán)代理有限公司 11006
• 代理人: 梁揮;祁建國

技術(shù)領(lǐng)域

一種網(wǎng)絡(luò)數(shù)據(jù)包的傳輸方法，特別涉及一種網(wǎng)絡(luò)多播的數(shù)據(jù)包重接收處理方法。?

背景技術(shù)

網(wǎng)絡(luò)多播(multicast)是一種允許一個或多個發(fā)送者發(fā)送單一的數(shù)據(jù)包到多個接收者的網(wǎng)絡(luò)技術(shù)。網(wǎng)絡(luò)多播數(shù)據(jù)包典型地使用用戶數(shù)據(jù)包協(xié)議(UserDatagram?Protocol，以下簡稱UDP)，而UDP是一種不可靠的數(shù)據(jù)包發(fā)送協(xié)議。在網(wǎng)絡(luò)數(shù)據(jù)包傳送擁塞的情況下會造成數(shù)據(jù)包的遺漏。因此就需要對遺漏的數(shù)據(jù)包進(jìn)行補(bǔ)發(fā)。?

在對遺漏的數(shù)據(jù)包進(jìn)行補(bǔ)發(fā)的過程中，由服務(wù)器端輪回式的重復(fù)發(fā)送數(shù)據(jù)包(換句話說，服務(wù)器端在發(fā)送完此一回合中的數(shù)據(jù)包后，會重頭開始傳送相同的數(shù)據(jù)包，直至客戶端完成所有數(shù)據(jù)包的接收)。服務(wù)器端不停的播發(fā)網(wǎng)絡(luò)多播數(shù)據(jù)包，客戶端可以在網(wǎng)絡(luò)多播過程的任意時刻加入接收數(shù)據(jù)包，直至客戶端判斷滿足網(wǎng)絡(luò)多播結(jié)束的條件后結(jié)束網(wǎng)絡(luò)多播并退出網(wǎng)絡(luò)多播組。?

一些公知的網(wǎng)絡(luò)多播結(jié)束檢測就會出現(xiàn)下列問題：(1).按照接收到的數(shù)據(jù)包與收到的第一個數(shù)據(jù)包相同為網(wǎng)絡(luò)多播結(jié)束條件。由于存在丟包現(xiàn)象，客戶端有可能永遠(yuǎn)也收不到那個數(shù)據(jù)包。這樣網(wǎng)絡(luò)多播就會永遠(yuǎn)也不能結(jié)束，客戶端就會一直占用著網(wǎng)絡(luò)頻寬。(2).設(shè)定網(wǎng)絡(luò)多播的一個預(yù)設(shè)時間，當(dāng)客戶端的接收時間超過預(yù)設(shè)時間時，則服務(wù)器端結(jié)束網(wǎng)絡(luò)多播。由于不同的網(wǎng)絡(luò)多播組發(fā)送的不同，且因為網(wǎng)絡(luò)傳輸?shù)挠绊懀菀讓?dǎo)致傳輸時間并不可靠。若是時間偏長就會浪費網(wǎng)絡(luò)頻寬和效率；但時間偏短又會導(dǎo)致網(wǎng)絡(luò)多播不能正常完成。(3).若對網(wǎng)絡(luò)多播數(shù)據(jù)包設(shè)定一個域值(即將數(shù)據(jù)包給予相應(yīng)的編號，并設(shè)定一個域值用以界定數(shù)據(jù)包的編號差)。當(dāng)收到的數(shù)據(jù)包位于這個范圍內(nèi)時，認(rèn)為網(wǎng)絡(luò)多播結(jié)束。這種方法如果在網(wǎng)絡(luò)比較擁塞時，有可能會收到這個范圍內(nèi)的補(bǔ)發(fā)的數(shù)據(jù)包，從而導(dǎo)致網(wǎng)絡(luò)多播過早結(jié)束。

上述幾種網(wǎng)絡(luò)多播結(jié)束檢測機(jī)制均不能滿足要求，而網(wǎng)絡(luò)多播結(jié)束的檢測技術(shù)在系統(tǒng)中起著重要的作用，處理不當(dāng)會造成很嚴(yán)重的影響。?

發(fā)明內(nèi)容

鑒于以上的問題，本發(fā)明所要解決的技術(shù)問題在于提供一種網(wǎng)絡(luò)多播的數(shù)據(jù)包重接收處理方法，服務(wù)器端應(yīng)用網(wǎng)絡(luò)多播(multicast)的用戶數(shù)據(jù)協(xié)議(UserDatagram?Protocol，UDP)發(fā)送多個數(shù)據(jù)包至客戶端。?

為實現(xiàn)上述目的，本發(fā)明所公開的一種網(wǎng)絡(luò)多播的數(shù)據(jù)包重接收處理方法包括以下步驟：由服務(wù)器端開始發(fā)送數(shù)據(jù)包；在第一時間開始，客戶端開始接收數(shù)據(jù)包；在第二時間時，客戶端執(zhí)行檢測程序，用以判斷第一時間至第二時間的期間所接收的數(shù)據(jù)包順序是否正確；在檢測程序檢測到數(shù)據(jù)包被遺漏時，則客戶端持續(xù)至少一回合的多播時間內(nèi)補(bǔ)齊所遺漏的數(shù)據(jù)包；在超過上述的多播時間后，則客戶端要求服務(wù)器端通過傳輸控制協(xié)議(Transmission?ControlProtocol，TCP)將數(shù)據(jù)包重新發(fā)送給客戶端；在客戶端完成接收數(shù)據(jù)包時，則客戶端停止接收數(shù)據(jù)包。?

本發(fā)明提供一種網(wǎng)絡(luò)多播的數(shù)據(jù)包重接收處理方法，特別針對多播方式的網(wǎng)絡(luò)數(shù)據(jù)包傳送的處理。客戶端可以在有限的時間中補(bǔ)齊遺漏的數(shù)據(jù)包，除了可以降低客戶端占用網(wǎng)絡(luò)頻寬的使用率外，客戶端亦可以接收到完整的多播內(nèi)容。若客戶端在預(yù)定的時限中未能補(bǔ)齊所有的數(shù)據(jù)包時，客戶端會先行停止接收來自服務(wù)器端的數(shù)據(jù)包。客戶端會另行向服務(wù)器端發(fā)送補(bǔ)送的要求，服務(wù)器端則利用傳輸控制協(xié)議的方式傳送客戶端所遺漏的數(shù)據(jù)包。?

下面結(jié)合附圖和具體實施例對本發(fā)明進(jìn)行詳細(xì)描述，但不作為對本發(fā)明的限定。?

附圖說明

圖1為本發(fā)明的數(shù)據(jù)包傳送順序示意圖；?

圖2為本發(fā)明的工作流程示意圖；?

圖3A為預(yù)設(shè)時間的設(shè)定流程示意圖；?

圖3B為預(yù)設(shè)時間的工作流程示意圖；?

圖3C為預(yù)設(shè)時間的示意圖；

圖3D為預(yù)設(shè)時間的示意圖；?

圖3E為本發(fā)明的目標(biāo)數(shù)據(jù)包的工作流程示意圖；?

圖3F為第一種狀況的范圍示意圖；?

圖3G為第二種狀況的范圍示意圖；?

圖3H為第三種狀況的范圍示意圖；?

圖4為接收效率的流程示意圖。?

其中，附圖標(biāo)記?

110????服務(wù)器端?

120????客戶端?

131????初始數(shù)據(jù)包?

132????臨界數(shù)據(jù)包?

133????目標(biāo)數(shù)據(jù)包?

具體實施方式