專利名稱：數(shù)據(jù)傳輸?shù)牟铄e控制方法
技術領域：
本發(fā)明涉及一種數(shù)據(jù)傳輸?shù)牟铄e控制方法，適用于在計算機網絡中傳輸大量數(shù)據(jù)，包括傳統(tǒng)的文件傳輸及利用P2P(端對端)技術進行文件傳輸，傳統(tǒng)的流媒體直播、點播以及利用P2P技術進行流媒體直播、點播等應用領域。
背景技術：
在計算機網絡中，數(shù)據(jù)主要以TCP(傳輸控制協(xié)議)或UDP(用戶數(shù)據(jù)報協(xié)議)來承載。
使用TCP時，收信端利用ACK(確認)機制，來通知發(fā)信端，它已經從發(fā)信端正確收到哪些數(shù)據(jù)塊，發(fā)信端以此來確定接下來要發(fā)送的數(shù)據(jù)塊的序號或需要重新發(fā)送的數(shù)據(jù)塊的序號。當數(shù)據(jù)被丟失時，TCP就靠這種檢測丟包重傳的機制，來保證數(shù)據(jù)的可靠傳輸。然而TCP的丟包重傳機制，會造成額外的網絡時延，在傳輸文件的時候，時延積累的結果是需要花更多的時間才能完成文件傳輸；在流媒體點播或直播的時候，時延積累的結果是很明顯的圖像停頓。
UDP是一種不保證可靠性的傳輸協(xié)議，一般地，在傳輸文件的時候，需要增加確認序號等差錯控制機制，來保障數(shù)據(jù)不被丟失；在流媒體點播或直播的時候，為保證數(shù)據(jù)能及時傳遞往往放棄差錯控制機制，如果有數(shù)據(jù)被丟失，則導致圖像黑屏或出現(xiàn)馬賽克。
無論是TCP的可靠傳輸，還是在UDP上增加需要確認序號的差錯控制，即使是網絡帶寬足夠富裕，在網絡有一定的丟包時，仍然將造成時間長度不可預測的傳輸時延，結果是導致文件傳輸時間變長，流媒體點播或直播時，圖像停頓、黑屏或出現(xiàn)馬賽克。
發(fā)明內容
1、發(fā)明目的本發(fā)明的目的是提供一種數(shù)據(jù)傳輸?shù)牟铄e控制方法，在網絡丟包率較高但帶寬足夠的情況下，它能有效地保障數(shù)據(jù)的快速、可靠傳輸。
2、技術方案一種數(shù)據(jù)傳輸?shù)牟铄e控制方法，其特征是它包括以下步驟(A)收信端發(fā)送請求給發(fā)信端，該請求包括收信端向發(fā)信端索取的數(shù)據(jù)集的標識及收信端可以接收數(shù)據(jù)的速率；(B)發(fā)信端對數(shù)據(jù)集進行全息編碼，然后以不高于收信端可接收數(shù)據(jù)的速率，向收信端發(fā)送至少一倍于解碼所需要的量的編碼數(shù)據(jù)；(C)收信端接收全息編碼數(shù)據(jù)的同時進行全息解碼，一旦解碼完畢，立即發(fā)送停發(fā)請求給發(fā)信端；
(D)發(fā)信端收到收信端的停發(fā)請求之后，停止向收信端發(fā)送編碼數(shù)據(jù)。
在上述方法中，還可以包括如下以下步驟(E)發(fā)信端發(fā)向收信端的編碼數(shù)據(jù)量，比解碼所需的數(shù)據(jù)量多一倍之后，如果還未收到收信端的停發(fā)請求，則停止繼續(xù)發(fā)送；(F)收信端由于接收到的編碼數(shù)據(jù)量不夠而無法解碼，如果等待規(guī)定的時間之后仍接收不到來自于發(fā)信端的編碼數(shù)據(jù)時，則再次發(fā)送請求給發(fā)信端，該請求包括收信端向發(fā)信端索取的數(shù)據(jù)集的標識及收信端可以接收數(shù)據(jù)的速率。
在上述步驟(B)、(C)中，所述的編碼、解碼方法，可以使用本申請人提出的第200510094180.5號發(fā)明專利所涉及的方法。
3、有益效果本發(fā)明與現(xiàn)有技術相比，其顯著優(yōu)點是利用本發(fā)明所述的差錯控制方法，在網絡丟包率較高但帶寬足夠的情況下，它能有效地保障數(shù)據(jù)的快速、可靠傳輸，縮短文件傳輸?shù)臅r間或減少流媒體點播及直播時圖像出現(xiàn)停頓、黑屏或馬賽克的現(xiàn)象。
四
附圖是差錯控制方法主要步驟的簡要邏輯圖。
五、具體實施方法結合附圖，詳細說明具體的實現(xiàn)方法(A)收信端發(fā)送請求給發(fā)信端，該請求包括收信端向發(fā)信端索取的數(shù)據(jù)集的標識及收信端可以接收數(shù)據(jù)的速率。
(B)發(fā)信端對數(shù)據(jù)集進行全息編碼如下假設收信端向發(fā)信端索取的原始數(shù)據(jù)集由數(shù)據(jù)塊X1、X2、X3、……、Xm構成，小寫英文字母m、n、k、s等為符號下標，是自然數(shù)。
生成隨機向量Ak＝<Ak1、Ak2、Ak3、……、Akm>，其中每個Akn都是隨機數(shù)；生成中間結果Pk＝(Ak1*X1)+(Ak2*X2)+(Ak3*X3)+……+(Akm*Xm)輸出全息編碼結果Yk為Ak與Pk的組合，例如，Ak為<1、2、3、4>，Pk轉換成字符串之后為abcdefg，則可組合成編碼結果Yk為字符串1_2_3_4_abcdefg。
發(fā)信端一邊進行全息編碼，一邊以不高于收信端可接收數(shù)據(jù)的速率，向收信端發(fā)送至少一倍(例如1-10倍)于解碼所需要的量的編碼數(shù)據(jù)。一般地，解碼所需的編碼數(shù)據(jù)的塊數(shù)，略高于原始數(shù)據(jù)集的數(shù)據(jù)的塊數(shù)m。
為加快編解碼速度，可以讓隨機向量Ak中的每個值Akn只能隨機為0或1，并且編碼或解碼時的加法運算，都改為異或運算。
(C)收信端接收全息編碼數(shù)據(jù)的同時進行全息解碼如下由全息編碼的方法可知，每個全息編碼數(shù)據(jù)都含有一部分的原始信息量，所以，只要收信端接收到編碼數(shù)據(jù)的塊數(shù)足夠，就可以解碼出完整的原始數(shù)據(jù)，其原因是沒有任何一塊編碼數(shù)據(jù)是關鍵數(shù)據(jù)塊，收信端不會因為缺少關鍵數(shù)據(jù)塊而無法進行解碼。只要網絡帶寬足夠，就算有較高的丟包率，收信端仍然能收到足夠的編碼數(shù)據(jù)，因而能夠有效解碼。
將接收到的s個(s必須大于或等于m)編碼數(shù)據(jù)Y1、Y2、Y3、……、Ys拆分，得到如下矩陣等式A11A12A13······A1mA21A22A23······A2m······Ak1Ak2Ak3······Akm······Am1Am2Am3······Amm······As1As2As3······Asm*X1X2X3······Xm=P1P2……Pk……Pm……Ps]]>解上述線性方程組，求得原始數(shù)據(jù)X1、X2、X3、……、Xm，一旦解碼完畢，立即發(fā)送停發(fā)請求給發(fā)信端。
(D)發(fā)信端收到收信端的停發(fā)請求之后，立即停止再往收信端發(fā)送編碼數(shù)據(jù)。由附圖可知，發(fā)信端有可能發(fā)送出比收信端解碼所需的數(shù)據(jù)量更多的編碼數(shù)據(jù)，但是，一旦發(fā)信端收到收信端的停發(fā)請求，發(fā)信端會立即停止發(fā)送，確保發(fā)信端多發(fā)送的編碼數(shù)據(jù)量很少，以避免浪費網絡帶寬。
為了防止收信端所發(fā)送的停發(fā)請求在網絡中被丟失的情況下，發(fā)信端仍然不停地往收信端發(fā)送編碼數(shù)據(jù)而浪費網絡帶寬，發(fā)信端需要進行如下判斷處理(E)發(fā)信端發(fā)往收信端的編碼數(shù)據(jù)量，比解碼所需的數(shù)據(jù)量多一倍之后，如果還未收到收信端的停發(fā)請求，則停止繼續(xù)發(fā)送。
為防止網絡連續(xù)丟失大批量數(shù)據(jù)的情況下收信端無法解碼，收信端需要進行如下判斷處理(F)收信端由于接收到的編碼數(shù)據(jù)量不夠而無法解碼，如果等待規(guī)定的時間(例如1微秒到9秒)之后仍接收不到來自于發(fā)信端的編碼數(shù)據(jù)，則再次發(fā)送請求給發(fā)信端，該請求包括收信端向發(fā)信端索取的數(shù)據(jù)集的標識及收信端可以接收數(shù)據(jù)的速率。無論編碼數(shù)據(jù)是哪次收到的，收信端都可以用它來進行解碼。
從上述詳細的實現(xiàn)方法可知，雖然這種數(shù)據(jù)傳輸?shù)牟铄e控制方法，可能會導致發(fā)信端發(fā)出比實際需要略多的數(shù)據(jù)量，但在網絡丟包率較高而帶寬足夠的情況下，它仍然能保障數(shù)據(jù)的可靠傳輸，同時，由于這種差錯控制方法無需序號確認機制，它還能保障數(shù)據(jù)的快速傳輸。例如，在計算機網絡中，上述請求及數(shù)據(jù)都采用UDP數(shù)據(jù)報來傳送，則利用這種差錯控制方法，可以很方便地在UDP之上，增加快速、可靠的數(shù)據(jù)傳輸控制機制，特別適合于流媒體點播及利用P2P技術進行流媒體直播等應用。
權利要求
1.一種數(shù)據(jù)傳輸?shù)牟铄e控制方法，其特征是它包括以下步驟(A)收信端發(fā)送請求給發(fā)信端，該請求包括收信端向發(fā)信端索取的數(shù)據(jù)集的標識及收信端可以接收數(shù)據(jù)的速率；(B)發(fā)信端對數(shù)據(jù)集進行全息編碼，然后以不高于收信端可接收數(shù)據(jù)的速率，向收信端發(fā)送至少一倍于解碼所需要的量的編碼數(shù)據(jù)；(C)收信端接收全息編碼數(shù)據(jù)的同時進行全息解碼，一旦解碼完畢，立即發(fā)送停發(fā)請求給發(fā)信端；(D)發(fā)信端收到收信端的停發(fā)請求之后，停止向收信端發(fā)送編碼數(shù)據(jù)。
2.根據(jù)權利要求1所述的數(shù)據(jù)傳輸?shù)牟铄e控制方法，其特征是它還可包括以下步驟(E)發(fā)信端發(fā)向收信端的編碼數(shù)據(jù)量，比解碼所需的數(shù)據(jù)量多一倍之后，如果還未收到收信端的停發(fā)請求，則停止繼續(xù)發(fā)送；(F)收信端由于接收到的編碼數(shù)據(jù)量不夠而無法解碼，如果等待規(guī)定的時間之后仍接收不到來自于發(fā)信端的編碼數(shù)據(jù)時，則再次發(fā)送請求給發(fā)信端，該請求包括收信端向發(fā)信端索取的數(shù)據(jù)集的標識及收信端可以接收數(shù)據(jù)的速率。
全文摘要
本發(fā)明公開一種數(shù)據(jù)傳輸?shù)牟铄e控制方法，適用于在計算機網絡中傳輸大量數(shù)據(jù)，它包括以下步驟收信端發(fā)送請求給發(fā)信端，該請求包括收信端向發(fā)信端索取的數(shù)據(jù)集的標識及收信端可以接收數(shù)據(jù)的速率；發(fā)信端對數(shù)據(jù)集進行全息編碼，然后以不高于收信端可接收數(shù)據(jù)的速率，向收信端發(fā)送至少一倍于解碼所需要的量的編碼數(shù)據(jù)；收信端接收全息編碼數(shù)據(jù)的同時進行全息解碼，一旦解碼完畢，立即發(fā)送停發(fā)請求給發(fā)信端；發(fā)信端收到收信端的停發(fā)請求之后，停止向收信端發(fā)送編碼數(shù)據(jù)。在網絡丟包率較高但帶寬足夠的情況下，它還能有效地保障數(shù)據(jù)的快速、可靠傳輸，縮短文件傳輸?shù)臅r間或減少流媒體點播及直播時圖像出現(xiàn)停頓、黑屏或馬賽克的現(xiàn)象。
文檔編號H04L1/00GK1747371SQ200510094410
公開日2006年3月15日 申請日期2005年9月16日 優(yōu)先權日2005年9月16日
發(fā)明者趙振平, 汪渝波, 鄒暢根 申請人:南京信風軟件有限公司