專利名稱：一種即時(shí)通信工具在線文件發(fā)送、接收方法及裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)技術(shù)領(lǐng)域，尤其涉及一種即時(shí)通信工具在線文件發(fā)送、接收方法及裝置。
背景技術(shù)：
即時(shí)通信(Instant Messaging簡(jiǎn)稱IM)是指通過(guò)即時(shí)通訊技術(shù)來(lái)實(shí)現(xiàn)在線雙方聊天、交流并能夠即時(shí)發(fā)送和接收互聯(lián)網(wǎng)消息等業(yè)務(wù)的通信方式。自1996年Mirabilis公司發(fā)布的第一款即時(shí)通信軟件ICQ以來(lái)，特別是近幾年應(yīng)用軟件的迅速發(fā)展，即時(shí)通信的功能日益豐富，逐漸集成了電子郵件、文件傳輸、音樂(lè)、電視、電子商務(wù)、游戲和搜索等多種功能。
根據(jù)CNNIC第24次《中國(guó)互聯(lián)網(wǎng)絡(luò)發(fā)展?fàn)顩r統(tǒng)計(jì)報(bào)告》調(diào)查顯示，中國(guó)網(wǎng)民即時(shí)通信服務(wù)使用率達(dá)到72.2%，成為繼網(wǎng)絡(luò)音樂(lè)、網(wǎng)絡(luò)新聞服務(wù)之后，第三大網(wǎng)絡(luò)服務(wù)。目前QQ在中國(guó)即時(shí)通信市場(chǎng)的用戶規(guī)模和收入規(guī)模占有絕對(duì)優(yōu)勢(shì)，整體即時(shí)通信用戶占有率高達(dá)97. 4%，以MSN Messenger為代表的國(guó)外綜合類即時(shí)通信軟件也在中國(guó)較高學(xué)歷群體和商務(wù)群體中占有較大比例。2009年即時(shí)通信軟件調(diào)查顯示，文件傳輸?shù)膽?yīng)用比例在50%以上。從以上數(shù)據(jù)可以看出利用即時(shí)通信軟件進(jìn)行文件傳輸已成為即時(shí)通信服務(wù)的重要內(nèi)容。利用即時(shí)通信軟件進(jìn)行文件傳輸和電子郵箱相比，由于省去了大數(shù)據(jù)量文件的上傳下載的步驟，因此更為方便快捷，但是，由于發(fā)送方和接收方都是在線等待數(shù)據(jù)傳輸?shù)慕Y(jié)束，因此更快更可靠的發(fā)送文件一直是頂軟件所追求的目標(biāo)?！銇?lái)說(shuō)，即時(shí)通信軟件進(jìn)行在線文件傳輸所采用的協(xié)議有TCP (TransmissionControl Protocol傳輸控制協(xié)議)和UDP (User Datagram Protocol用戶數(shù)據(jù)包協(xié)議)協(xié)議，而不同的即時(shí)通信軟件在這兩種協(xié)議的基礎(chǔ)上進(jìn)行了不同的優(yōu)化。MSN在線文件傳輸技術(shù)采用的是TCP協(xié)議，TCP協(xié)議位于OSI模型的運(yùn)輸層，是面向連接的可靠的數(shù)據(jù)流傳送協(xié)議。其客戶端和服務(wù)端建立通信鏈路都要經(jīng)過(guò)三次握手，圖I即為TCP協(xié)議建立連接時(shí)三次握手的示意圖，當(dāng)數(shù)據(jù)傳輸完畢，連接的斷開也同樣需要握手才可以完成，它的服務(wù)目標(biāo)是為了向應(yīng)用層提供可靠的端到端的數(shù)據(jù)流。由此可以看出，MSN采用的TCP協(xié)議在保證文件傳輸可靠性方面優(yōu)勢(shì)明顯，MSN進(jìn)行文件傳輸時(shí)，在較好的信道條件下，能夠較快較好的完成文件傳輸?shù)娜蝿?wù)。但是衡量一個(gè)文件傳輸機(jī)制是否優(yōu)良更多的是應(yīng)考慮其在較差的信道條件下的表現(xiàn)，那么在較差的信道條件下，文件傳輸出現(xiàn)延時(shí)和線路因反饋造成的擁堵往往不可避免。同時(shí)，在使用TCP的廣域網(wǎng)上兩個(gè)遠(yuǎn)點(diǎn)之間的文件傳輸也不能最大化的利用可用帶寬，產(chǎn)生冗長(zhǎng)的傳輸時(shí)間在所難免。根據(jù)以上描述可以看出TCP協(xié)議本身也較為復(fù)雜，因此TCP幀結(jié)構(gòu)也必然復(fù)雜。圖2即為TCP的幀結(jié)構(gòu)示意圖，綜上，對(duì)于MSN所采用的TCP協(xié)議來(lái)說(shuō)并不能算是一個(gè)完美的傳輸方案。同MSN在線傳輸文件只采用TCP協(xié)議有所不同，QQ采用了 TCP和UDP兩種協(xié)議。QQ進(jìn)行在線文件傳輸時(shí)，發(fā)送端計(jì)算機(jī)首先通過(guò)消息服務(wù)器將登錄時(shí)保留的IP地址發(fā)送給接收端計(jì)算機(jī)，接收端計(jì)算機(jī)的用戶在確定接收此文件后將發(fā)出一個(gè)同意的反饋，并將確認(rèn)接收消息發(fā)送到消息服務(wù)器，據(jù)此，消息服務(wù)器進(jìn)行文件傳輸對(duì)話的設(shè)置。然后，發(fā)送端服務(wù)器和接收端服務(wù)器根據(jù)事先確定的端口建立UDP或TCP協(xié)議鏈接，開始文件的傳輸。在通常情況下，QQ首先默認(rèn)采用UDP協(xié)議，其分配的端口為8000，8001。如果UDP的兩個(gè)端口不通，會(huì)自動(dòng)轉(zhuǎn)換到TCP 80端口或者TCP 443端口進(jìn)行通訊。UDP協(xié)議是OS I參考模型中一種面向無(wú)連接的傳輸協(xié)議，在網(wǎng)絡(luò)中它與TCP協(xié)議一樣同處于OSI模型的第四層——運(yùn)輸層，被用于處理UDP數(shù)據(jù)包。相比較TCP協(xié)議，UDP協(xié)議由于是面向無(wú)連接，提供的是不可靠傳輸服務(wù)，因此UDP協(xié)議的原理和幀結(jié)構(gòu)都較TCP簡(jiǎn)單很多。圖3為UDP協(xié)議幀結(jié)構(gòu)。因此，用QQ進(jìn)行文件傳輸?shù)乃俣容^其他的即時(shí)通信軟件的傳輸速度更快，但是這也并不是說(shuō)QQ的文件傳輸方式就是一個(gè)完美的方案，即使QQ在一定環(huán)境中可以將TCP協(xié)議切換為UDP協(xié)議，文件傳輸速度得以提高，但是由于UDP協(xié)議的不可靠性使得文件的傳輸沒(méi)有可靠性的保證。介于對(duì)以上傳輸協(xié)議的分析可知，傳統(tǒng)的即時(shí)通信軟件對(duì)于在線文件的傳輸并沒(méi)有一個(gè)既能像TCP協(xié)議一樣保證文件傳輸?shù)目煽啃裕帜芟馯DP協(xié)議一樣保證文件傳輸速率的傳輸協(xié)議。

發(fā)明內(nèi)容
本發(fā)明解決的技術(shù)問(wèn)題是如何采用噴泉碼FEC跨層設(shè)計(jì)思路，進(jìn)一步提升傳統(tǒng)即時(shí)通信工具在線文件傳輸?shù)男阅堋榱私鉀Q以上技術(shù)問(wèn)題，本發(fā)明實(shí)施例公開了一種即時(shí)通信工具在線文件發(fā)送方法，包括以下步驟I. I)將待發(fā)送文件數(shù)據(jù)進(jìn)行打包封裝成若干個(gè)數(shù)據(jù)包，在發(fā)送應(yīng)用層以數(shù)據(jù)包為單位進(jìn)行Raptor碼編碼，并加載循環(huán)冗余碼CRC后傳遞至發(fā)送端運(yùn)輸層；I. 2)運(yùn)輸層采用UDP協(xié)議轉(zhuǎn)換后傳遞至物理層；·I. 3)物理層對(duì)數(shù)據(jù)包進(jìn)行信道編碼與調(diào)制后傳遞至網(wǎng)絡(luò)信道。進(jìn)一步，作為優(yōu)選，Raptor碼編碼后的數(shù)據(jù)包根據(jù)接收端情況源源不斷產(chǎn)生。進(jìn)一步，作為優(yōu)選，在所述I. 2)加載循環(huán)冗余碼CRC之前，綜合信道條件和/或CPU負(fù)載因素選擇一個(gè)或以上Raptor碼編碼后的數(shù)據(jù)包合并為一個(gè)數(shù)據(jù)包。本發(fā)明實(shí)施例還公開了一種即時(shí)通信工具在線文件接收方法，發(fā)端應(yīng)用層Raptor編碼器和收端應(yīng)用層Raptor譯碼器之間所有模塊，為具有一定丟包率的刪除信道，包括以下步驟4. I)接收端物理層對(duì)接收數(shù)據(jù)包進(jìn)行信道解調(diào)與解碼后傳遞至接收端運(yùn)輸層；4. 2)接收端運(yùn)輸層根據(jù)UDP協(xié)議將報(bào)文頭數(shù)據(jù)去除，并取出信息數(shù)據(jù)后傳遞至接收端應(yīng)用層；4. 3 接收端應(yīng)用層的CRC模塊用以校驗(yàn)接收到的獨(dú)立數(shù)據(jù)包是否損壞或不完整，若數(shù)據(jù)包損壞或者不完整，將數(shù)據(jù)包進(jìn)行刪除，若數(shù)據(jù)包完整且正確，則將完整且正確的數(shù)據(jù)包發(fā)送至Raptor碼解碼器進(jìn)行譯碼；
4. 4)接收端應(yīng)用層Raptor譯碼器從等同的刪除信道中接收到前后無(wú)關(guān)聯(lián)、先后無(wú)次序的獨(dú)立數(shù)據(jù)包，若接收到的數(shù)據(jù)包數(shù)量大于原數(shù)據(jù)包數(shù)量，Raptor譯碼器譯碼結(jié)束；若超過(guò)一定時(shí)限，Raptor碼譯碼器仍未接收到足夠多的編碼數(shù)據(jù)包，根據(jù)事先設(shè)置向發(fā)送端發(fā)出繼續(xù)發(fā)送指示或者提醒用戶進(jìn)行下一步動(dòng)作的選擇。本發(fā)明實(shí)施例還公開了一種即時(shí)通信工具在線文件發(fā)送接收方法，包括一種即時(shí)通信工具在線文件發(fā)送方法和一種即時(shí)通信工具在線文件接收方法。本發(fā)明實(shí)施例還公開了一種即時(shí)通信工具在線文件發(fā)送裝置，包括順序連接的發(fā)送端應(yīng)用層、發(fā)送端運(yùn)輸層和發(fā)送端物理層；所述發(fā)送端應(yīng)用層包括順序連接的打包封裝模塊、Raptor編碼模塊和CRC編碼模塊，打包封裝模塊用于將待發(fā)送文件數(shù)據(jù)進(jìn)行打包封裝成若干個(gè)數(shù)據(jù)包，Raptor編碼模塊用于Raptor碼編碼，CRC編碼模塊用于加載循環(huán)冗余碼CRC ;所述發(fā)送端運(yùn)輸層包括UDP協(xié)議模塊，UDP協(xié)議模塊用于將數(shù)據(jù)包進(jìn)行UDP協(xié)議轉(zhuǎn)換；所述發(fā)送端物理層包括順序連接的物理層編碼模塊和物理層調(diào)制模塊，物理層編碼模塊用于對(duì)數(shù)據(jù)包進(jìn)行信道編碼，物理層調(diào)制模塊用于對(duì)信道編碼后的數(shù)據(jù)進(jìn)行信道調(diào)制。本發(fā)明實(shí)施例還公開了一種即時(shí)通信工具在線文件接收裝置，發(fā)端應(yīng)用層Raptor編碼器和收端應(yīng)用層Raptor譯碼器之間所有模塊，為具有一定丟包率的刪除信道，包括順序連接的接收端物理層、接收端運(yùn)輸層和接收端應(yīng)用層；所述接收端物理層包括順序連接的物理層解調(diào)模塊和物理層譯碼模塊，物理層解調(diào)模塊用于對(duì)數(shù)據(jù)包進(jìn)行信道解調(diào)，物理層譯碼模塊用于對(duì)信道解調(diào)后的數(shù)據(jù)進(jìn)行信道譯碼；所述接收端運(yùn)輸層包括UDP協(xié)議模塊，UDP協(xié)議模塊用于根據(jù)UDP協(xié)議將報(bào)文頭數(shù)據(jù)去除，并取出信息數(shù)據(jù)后傳遞至接收端應(yīng)用層；所述接收端應(yīng)用層包括順序連接的CRC校驗(yàn)?zāi)K、刪除模塊、Raptor譯碼器模塊和Raptor譯碼模塊，CRC校驗(yàn)?zāi)K用于檢測(cè)接收到的獨(dú)立數(shù)據(jù)包是否完整且正確，若數(shù)據(jù)包損壞或者不完整，送入刪除模塊將數(shù)據(jù)包進(jìn)行刪除，若數(shù)據(jù)包完整且正確，將完整且正確的數(shù)據(jù)包再分包發(fā)送至Raptor碼譯碼器模塊進(jìn)行譯碼；Rapt0r譯碼模塊用于判斷接收到的數(shù)據(jù)包數(shù)量和譯碼，完成等同刪除信道條件下原發(fā)送文件的恢復(fù)，若Raptor譯碼器模塊接收到完整且正確的數(shù)據(jù)包數(shù)量大于原數(shù)據(jù)包數(shù)量，譯碼結(jié)束；若超過(guò)一定時(shí)限，Raptor碼譯碼器仍未接收到足夠多完整且正確的編碼數(shù)據(jù)包，根據(jù)事先設(shè)置向發(fā)端發(fā)出繼續(xù)發(fā)送指示或者提醒用戶進(jìn)行下一步動(dòng)作的選擇。本發(fā)明實(shí)施例還公開了一種即時(shí)通信工具在線文件發(fā)送接收系統(tǒng)，包括一種即時(shí)通信工具在線文件發(fā)送裝置、一種即時(shí)通信工具在線文件接收裝置以及連接它們的網(wǎng)絡(luò)。本發(fā)明通過(guò)利用噴泉碼(Raptor碼)FEC技術(shù)的跨層設(shè)計(jì)方案，可以在文件傳輸中兼獲m)P協(xié)議的無(wú)連接快速性和TCP的可靠性，本發(fā)明克服在線文件傳輸選用TCP協(xié)議的效率低下或選用UDP協(xié)議的數(shù)據(jù)不可靠的缺點(diǎn)，同時(shí)保證文件傳輸?shù)目煽啃耘c快速性。按照本發(fā)明的方案比較QQ等即時(shí)通信工具的文件傳輸性能，比較測(cè)試結(jié)果顯示本發(fā)明方案在多種網(wǎng)絡(luò)(有線局域網(wǎng)、有線廣域網(wǎng)、WiFi、3G等網(wǎng)絡(luò))上傳輸文件(文件大小10MB以上)的速度較QQ等即時(shí)通信工具的傳輸速度提高30%或以上。


當(dāng)結(jié)合附圖考慮時(shí)，通過(guò)參照下面的詳細(xì)描述，能夠更完整更好地理解本發(fā)明以及容易得知其中許多伴隨的優(yōu)點(diǎn)，但此處所說(shuō)明的附圖用來(lái)提供對(duì)本發(fā)明的進(jìn)一步理解，構(gòu)成本發(fā)明的一部分，本發(fā)明的示意性實(shí)施例及其說(shuō)明用于解釋本發(fā)明，并不構(gòu)成對(duì)本發(fā)明的不當(dāng)限定，其中圖I是TCP協(xié)議建立連接的握手過(guò)程示意圖。圖2是TCP協(xié)議幀結(jié)構(gòu)示意圖。圖3是UDP協(xié)議幀結(jié)構(gòu)示意圖。圖4本發(fā)明實(shí)施例Raptor碼FEC結(jié)合UDP協(xié)議的跨層設(shè)計(jì)示意圖。圖5是發(fā)送端應(yīng)用層Raptor編碼流程示意圖。
具體實(shí)施方式
參照?qǐng)D4-5對(duì)本發(fā)明的實(shí)施例進(jìn)行說(shuō)明。為使上述目的、特征和優(yōu)點(diǎn)能夠更加明顯易懂，下面結(jié)合附圖和具體實(shí)施方式
對(duì)本發(fā)明作進(jìn)一步詳細(xì)的說(shuō)明。數(shù)字噴泉碼(Raptor碼)的概念最早由M. Luby于1998年提出，所謂數(shù)字噴泉碼的概念就是指將不斷編碼發(fā)送碼字的過(guò)程可以看成一個(gè)噴泉，無(wú)窮無(wú)盡地向外噴水滴。接收端則類似一個(gè)接水的水杯。由于各碼字的獨(dú)立隨機(jī)性，每塊碼字均包含信源信息，接收端并不關(guān)心接收到的是“哪滴水”。所以經(jīng)過(guò)刪除信道時(shí)，刪除編碼信息的任意部分，不會(huì)影響其他符號(hào)信息參與譯碼。LT碼和Raptor碼最早都是基于LDPC碼的原理，為刪除信道而設(shè)計(jì)的，適合于計(jì)算機(jī)網(wǎng)絡(luò)廣播。隨著噴泉碼理論研究的不斷深入，采用軟譯碼解碼并結(jié)合CRC等校驗(yàn)技術(shù)的噴泉碼幾乎可以在各種信道下提升系統(tǒng)的通信性能。Luby于2002年提出了第一種高效現(xiàn)實(shí)可行的噴泉碼——LT碼。其后，為了解決LT碼解碼時(shí)空不固定等缺點(diǎn)，Shokrollahi等人在LT碼編譯碼時(shí)間方面做了進(jìn)一步改進(jìn)，這種經(jīng)過(guò)改進(jìn)的新型噴泉碼被命名為Raptor碼，實(shí)現(xiàn)了近乎理想的編譯碼性能。本發(fā)明以較為先進(jìn)的Raptor碼為例，闡述采用噴泉碼FEC技術(shù)結(jié)合跨層設(shè)計(jì)思路來(lái)進(jìn)一步提高即時(shí)通信軟件的傳輸性能。一種即時(shí)通信工具在線文件發(fā)送接收方法，發(fā)端應(yīng)用層Raptor編碼器和收端應(yīng)用層Raptor譯碼器之間所有模塊，包含發(fā)收端CRC編譯碼器、OSI中間各層、傳輸信道及刪除模塊可視為具有一定丟包率的刪除信道，包括以下步驟I)將待發(fā)送文件數(shù)據(jù)進(jìn)行打包封裝成若干個(gè)數(shù)據(jù)包，在發(fā)送端應(yīng)用層以數(shù)據(jù)包為單位進(jìn)行Raptor碼編碼，Raptor編碼后的數(shù)據(jù)包根據(jù)接收端情況源源不斷產(chǎn)生；綜合信道條件、CPU負(fù)載等因素選擇多個(gè)(可以為一個(gè))噴泉碼編碼后的數(shù)據(jù)包進(jìn)行合并為一個(gè)數(shù)據(jù)包，并加載循環(huán)冗余碼CRC，將發(fā)送端應(yīng)用層最終生成的編碼數(shù)據(jù)包經(jīng)發(fā)送端表示層、會(huì)話層等層傳遞至發(fā)送端運(yùn)輸層。2)數(shù)據(jù)包傳遞至發(fā)送端運(yùn)輸層，運(yùn)輸層選用面向無(wú)連接的不可靠的UDP協(xié)議；采用這種吞吐量不受擁擠控制算法的協(xié)議，并考慮應(yīng)用層編碼數(shù)據(jù)包的產(chǎn)生速率、傳輸帶寬等因素的限制，最大化文件數(shù)據(jù)包的傳輸速率，將數(shù)據(jù)包傳遞至發(fā)送端物理層。3)數(shù)據(jù)包傳遞至發(fā)送端物理層，發(fā)送端物理層根據(jù)信道特征選用適當(dāng)?shù)恼{(diào)制方式與信道編碼。將數(shù)據(jù)包傳遞至網(wǎng)絡(luò)信道。在網(wǎng)絡(luò)信道傳遞，有的由于信道的刪除特性丟失，有數(shù)據(jù)包因?yàn)樾诺涝肼晫?dǎo)致發(fā)送的數(shù)據(jù)包包含錯(cuò)誤或損壞。4)部分包含錯(cuò)誤的數(shù)據(jù)包傳遞至接收端物理層進(jìn)行解調(diào)與解碼，在此過(guò)程中可以通過(guò)接收端物理層信道編碼的選擇糾錯(cuò)部分包含錯(cuò)誤數(shù)據(jù)的數(shù)據(jù)包，降低包含錯(cuò)誤數(shù)據(jù)包占總接收到數(shù)據(jù)包的比例。將經(jīng)過(guò)接收端物理層解調(diào)與解碼的數(shù)據(jù)包經(jīng)多層傳遞至接收端運(yùn)輸層。5)接收端運(yùn)輸層根據(jù)UDP協(xié)議將報(bào)文頭數(shù)據(jù)去除，并取出信息數(shù)據(jù)傳遞至接收端
應(yīng)用層。6) 數(shù)據(jù)包傳遞至接收端應(yīng)用層，接收端應(yīng)用層CRC校驗(yàn)?zāi)K用于檢測(cè)接收到的數(shù)據(jù)包是否完整且正確，若數(shù)據(jù)包損壞或者不完整，送入刪除模塊將數(shù)據(jù)包進(jìn)行刪除，若數(shù)據(jù)包中完整且正確，將完整且正確的數(shù)據(jù)包發(fā)送至Raptor碼解碼器模塊進(jìn)行譯碼。7)若Raptor譯碼器接收到得數(shù)據(jù)包數(shù)量略大于原數(shù)據(jù)包數(shù)量，Raptor碼譯碼器能以極高的成功率進(jìn)行譯碼；若超過(guò)一定時(shí)限，Raptor碼譯碼器仍未接收到足夠多的編碼數(shù)據(jù)包，可以根據(jù)事先設(shè)置向發(fā)送端發(fā)出繼續(xù)發(fā)送指示或者提醒用戶進(jìn)行下一步動(dòng)作的選擇。如圖5所示，為發(fā)送端的應(yīng)用層Raptor編碼流程圖，將包含KXa個(gè)bit的待發(fā)送源文件分割成K個(gè)源符號(hào)，每個(gè)源符號(hào)包含a個(gè)bit，然后以包為單位對(duì)K個(gè)源符號(hào)進(jìn)行噴泉碼編碼，源源不斷的產(chǎn)生編碼符號(hào)，但根據(jù)實(shí)際需要不斷的產(chǎn)生編碼符號(hào)是沒(méi)有必要且不現(xiàn)實(shí)的，因此將產(chǎn)生的編碼數(shù)據(jù)符號(hào)數(shù)量設(shè)定為最多K'個(gè)，K' =K+0Verhead，其中overhead為實(shí)際設(shè)定的譯碼開銷。經(jīng)過(guò)噴泉碼編碼后不斷產(chǎn)生的K' Raptor編碼數(shù)據(jù)包，以N(N為正整數(shù)，且NS I)個(gè)數(shù)據(jù)包為單位組合并進(jìn)行CRC編碼，加載CRC校驗(yàn)，服務(wù)端應(yīng)用層的編碼結(jié)束。編碼數(shù)據(jù)包經(jīng)過(guò)網(wǎng)絡(luò)信道最終到達(dá)接收端應(yīng)用層，假設(shè)接收端的應(yīng)用層接收到的編碼數(shù)據(jù)包數(shù)量為W個(gè)，經(jīng)過(guò)CRC校驗(yàn)后將損壞或不完整的E個(gè)數(shù)據(jù)包丟棄，實(shí)際噴泉碼解碼器接收到的數(shù)據(jù)包數(shù)量為R=W_E。當(dāng)滿足R略大于源符號(hào)數(shù)量K時(shí)，噴泉碼解碼器基本就可以成功譯碼并輸出復(fù)原的數(shù)據(jù)文件，此時(shí)，接收端發(fā)送一個(gè)反饋告知接收端整個(gè)在線文件發(fā)送過(guò)程成功；當(dāng)發(fā)送端將K,個(gè)數(shù)據(jù)包全部發(fā)送完畢，此時(shí)R少于源符號(hào)的數(shù)量K時(shí)，或雖然滿足R略大于源符號(hào)數(shù)量K無(wú)法譯碼成功時(shí)(不同的噴泉碼設(shè)計(jì)會(huì)有不同的譯碼失敗的概率，但此概率極低)，發(fā)送端也將發(fā)送一個(gè)反饋告知接收端繼續(xù)發(fā)送編碼數(shù)據(jù)包或繼續(xù)進(jìn)行下一步程序的規(guī)定動(dòng)作。如圖4所示，一種即時(shí)通信工具在線文件發(fā)送接收系統(tǒng)，包括發(fā)送裝置、接收裝置及連接它們的網(wǎng)絡(luò)4，發(fā)送裝置包括順序連接的發(fā)送端應(yīng)用層I、發(fā)送端運(yùn)輸層2和發(fā)送端物理層3 ;所述發(fā)送端應(yīng)用層I包括順序連接的打包封裝模塊11、Raptor編碼模塊12和CRC編碼模塊13，打包封裝模塊11用于將待發(fā)送文件數(shù)據(jù)進(jìn)行打包封裝成若干個(gè)數(shù)據(jù)包，Raptor編碼模塊12用于Raptor碼編碼，CRC編碼模塊13用于加載循環(huán)冗余碼CRC ;所述發(fā)送端運(yùn)輸層2包括UDP協(xié)議模塊21，UDP協(xié)議模塊21用于將數(shù)據(jù)包進(jìn)行UDP協(xié)議轉(zhuǎn)換；所述發(fā)送端物理層3包括順序連接的物理層編碼模塊31和物理層調(diào)制模塊32，物理層編碼模塊31用于對(duì)數(shù)據(jù)包進(jìn)行信道編碼，物理層調(diào)制模塊32用于對(duì)信道編碼后的數(shù)據(jù)進(jìn)行信道調(diào)制。接收裝置包括順序連接的接收端物理層5、接收端運(yùn)輸層6和接收端應(yīng)用層7 ;所述接收端物理層5包括順序連接的物理層解調(diào)模塊51和物理層譯碼模塊52，物理層解調(diào)模塊51用于對(duì)數(shù)據(jù)包進(jìn)行信道解調(diào)，物理層譯碼模塊52用于對(duì)信道解調(diào)后的數(shù)據(jù)進(jìn)行信道譯碼；所述接收端運(yùn)輸層6包括UDP協(xié)議模塊61，UDP協(xié)議模塊61用于根據(jù)UDP協(xié)議將報(bào)文頭數(shù)據(jù)去除，并取出信息數(shù)據(jù)后傳遞至接收端應(yīng)用層7 ;所述接收端應(yīng)用層7包括順序連接的CRC校驗(yàn)?zāi)K71、刪除模塊73、Raptor譯碼器模塊72和Raptor譯碼模塊74，CRC校驗(yàn)?zāi)K71用于檢測(cè)接收到的數(shù)據(jù)包是否完整且正確，經(jīng)過(guò)校驗(yàn)檢測(cè)判斷，若數(shù)據(jù)包損壞或者不完整，送入刪除模塊73將數(shù)據(jù)包進(jìn)行刪除，若數(shù)據(jù)包中完整且正確，將完整且正確的數(shù)據(jù)包發(fā)送至Raptor碼譯碼器模塊72進(jìn)行譯碼，Raptor譯碼模塊74用于判斷若Raptor譯碼器模塊72接收到得數(shù)據(jù)包數(shù)量大于原數(shù)據(jù)包數(shù)量，譯碼結(jié)束；若超過(guò)一定時(shí)限，Raptor譯碼器72仍未接收到足夠多的編碼數(shù)據(jù)包，根據(jù)事先設(shè)置向發(fā)送端發(fā)出繼續(xù)發(fā)送指示或者提醒用戶進(jìn)行下一步動(dòng)作的選擇。利用噴泉碼FEC技術(shù)的跨層設(shè)計(jì)方案可以在文件傳輸中兼獲UDP協(xié)議的無(wú)連接快速性和TCP的可靠性。本發(fā)明和QQ在線文件傳輸協(xié) 議比較具有如下優(yōu)點(diǎn)(I)噴泉碼FEC技術(shù)的跨層設(shè)計(jì)可以免去QQ在文件傳輸時(shí)選擇傳輸協(xié)議的過(guò)程QQ在文件傳輸服務(wù)進(jìn)行前，首先要根據(jù)不同的網(wǎng)絡(luò)性質(zhì)和文件的可靠性級(jí)別進(jìn)行TCP和UDP協(xié)議的選擇，而使用噴泉碼技術(shù)可以省去這一過(guò)程。作為一種普適性好碼，噴泉碼技術(shù)優(yōu)勢(shì)之一在于不論何種網(wǎng)絡(luò)，采用應(yīng)用層噴泉碼編碼結(jié)合運(yùn)輸層的UDP協(xié)議的跨層設(shè)計(jì)，都能達(dá)到幾近理想的性能。(2)噴泉碼FEC技術(shù)的跨層設(shè)計(jì)比較QQ文件傳輸中TCP協(xié)議的優(yōu)勢(shì)QQ文件傳輸所用的TCP協(xié)議是一種面向連接的端對(duì)端可靠傳輸協(xié)議，它在兩個(gè)通信終端建立會(huì)話。為了保證可靠性，TCP使用序列號(hào)、確定應(yīng)答、超時(shí)設(shè)定和重發(fā)等手段。在發(fā)送端和接收端之間，TCP的數(shù)據(jù)傳輸控制和阻塞避免機(jī)制用來(lái)監(jiān)視往返時(shí)間，此協(xié)議假設(shè)過(guò)長(zhǎng)的往返時(shí)間是由于網(wǎng)絡(luò)阻塞的原因造成的，而不是由于實(shí)際的傳輸時(shí)間造成的。TCP需要接收端應(yīng)答成功收到數(shù)據(jù)包，如果在超時(shí)期限內(nèi)發(fā)送端沒(méi)有接收應(yīng)答，TCP會(huì)通過(guò)將發(fā)送端降低數(shù)據(jù)包發(fā)送速度以應(yīng)對(duì)這一問(wèn)題。因此，在使用TCP的廣域網(wǎng)上兩個(gè)遠(yuǎn)點(diǎn)之間的文件傳輸不能利用可用帶寬，并產(chǎn)生了冗長(zhǎng)的傳輸時(shí)間。所以，對(duì)于TCP來(lái)說(shuō)，其可靠性的保證是以帶寬低效為代價(jià)取得的。噴泉碼FEC技術(shù)的跨層設(shè)計(jì)和TCP相比，在確保可靠性的同時(shí)，仍然允許充分利用所有可用的帶寬。根據(jù)噴泉碼技術(shù)的原理可知，接收端計(jì)算機(jī)通過(guò)接收足夠多數(shù)量的數(shù)據(jù)包進(jìn)行解碼，在確定了所得到數(shù)據(jù)文件的完整性與正確性以后，才將反饋給發(fā)送端一個(gè)確定文件傳輸成功的應(yīng)答，那么在文件傳輸過(guò)程中，省去了 TCP對(duì)每一個(gè)數(shù)據(jù)包的反饋應(yīng)答，這在網(wǎng)絡(luò)信道條件較差的情況下，其優(yōu)勢(shì)更為突出。綜上可知，如果利用噴泉碼FEC技術(shù)的跨層設(shè)計(jì)替代TCP協(xié)議進(jìn)行QQ文件的傳輸，可以在保證文件傳輸?shù)目煽啃酝瑫r(shí)可以加速文件的傳輸時(shí)間，并更好的利用網(wǎng)絡(luò)資源以實(shí)現(xiàn)高效的寬帶利用率。(3)應(yīng)用層噴泉碼FEC技術(shù)結(jié)合運(yùn)輸層UDP協(xié)議較單獨(dú)使用UDP協(xié)議的優(yōu)勢(shì)QQ文件傳輸所用的UDP協(xié)議是位于OSI參考模型傳輸層的一種無(wú)連接型協(xié)議。因其不需要像TCP協(xié)議那樣在數(shù)據(jù)發(fā)送前要事先握手和發(fā)送時(shí)的反饋應(yīng)答，而具有資源消耗小，處理速度快的優(yōu)點(diǎn)，所以通常音頻、視頻和普通數(shù)據(jù)在傳送時(shí)使用UDP較多，因?yàn)樗鼈兗词古紶杹G失一兩個(gè)數(shù)據(jù)包，也不會(huì)對(duì)接收結(jié)果產(chǎn)生太大影響。但在網(wǎng)絡(luò)質(zhì)量比較差的環(huán)境下，UDP協(xié)議數(shù)據(jù)的包丟失會(huì)比較嚴(yán)重，這會(huì)使得客戶體驗(yàn)感受大大降低。將應(yīng)用層的噴泉碼技術(shù)結(jié)合UDP協(xié)議的無(wú)連接特性，其文件傳輸?shù)目煽啃钥捎蓢娙a的糾刪技術(shù)得以保證。噴泉碼技術(shù)本身由于眾多的科研人員對(duì)其算法的不斷優(yōu)化，其編譯碼的計(jì)算復(fù)雜度和對(duì)計(jì)算機(jī)cpu的處理速度要求已經(jīng)很低了，噴泉碼的編譯碼所消耗的時(shí)間同文件傳輸?shù)臅r(shí)間相比幾乎可以忽略，特別是在網(wǎng)絡(luò)信道條件較差的情況下，由于噴泉碼技術(shù)所帶來(lái)的巨大優(yōu)勢(shì)(文件發(fā)送速度和文件傳輸可靠性)和其編譯碼所需的時(shí)間和資源來(lái)說(shuō)是償遠(yuǎn)大于失的。 雖然以上描述了本發(fā)明的具體實(shí)施方式
，但是本領(lǐng)域的技術(shù)人員應(yīng)當(dāng)理解，這些具體實(shí)施方式
僅是舉例說(shuō)明，本領(lǐng)域的技術(shù)人員在不脫離本發(fā)明的原理和實(shí)質(zhì)的情況下，可以對(duì)上述方法和系統(tǒng)的細(xì)節(jié)進(jìn)行各種省略、替換和改變。例如，合并上述方法步驟，從而按照實(shí)質(zhì)相同的方法執(zhí)行實(shí)質(zhì)相同的功能以實(shí)現(xiàn)實(shí)質(zhì)相同的結(jié)果則屬于本發(fā)明的范圍。因此，本發(fā)明的范圍僅由所附權(quán)利要求書限定。
權(quán)利要求
1. 一種即時(shí)通信工具在線文件發(fā)送方法，其特征在于，包括以下步驟 .1.1)將待發(fā)送文件數(shù)據(jù)進(jìn)行打包封裝成若干個(gè)數(shù)據(jù)包，在發(fā)端應(yīng)用層以數(shù)據(jù)包為單位進(jìn)行Raptor碼編碼，編碼后的數(shù)據(jù)包之間相互獨(dú)立，性能等同，其后加載循環(huán)冗余碼CRC后傳遞至發(fā)送端運(yùn)輸層； I. 2)運(yùn)輸層采用UDP協(xié)議轉(zhuǎn)換后傳遞至物理層； . 1.3)物理層對(duì)數(shù)據(jù)包進(jìn)行信道編碼與調(diào)制后傳遞至網(wǎng)絡(luò)信道。
2.根據(jù)權(quán)利要求I所述的即時(shí)通信工具在線文件發(fā)送方法，其特征在于，所述Raptor碼編碼后的數(shù)據(jù)包根據(jù)接收端情況源源不斷產(chǎn)生。
3.根據(jù)權(quán)利要求I所述的即時(shí)通信工具在線文件發(fā)送方法，其特征在于，在所述I.2)加載循環(huán)冗余碼CRC之前，綜合信道條件和/或CPU負(fù)載因素選擇一個(gè)或以上Raptor碼編碼后的數(shù)據(jù)包合并為一個(gè)數(shù)據(jù)包。
4.一種即時(shí)通信工具在線文件接收方法，發(fā)端應(yīng)用層Raptor編碼器和收端應(yīng)用層Raptor譯碼器之間所有模塊，為具有一定丟包率的刪除信道； 其特征在于，包括以下步驟 .4. I)接收端物理層對(duì)接收數(shù)據(jù)包進(jìn)行信道解調(diào)與解碼后傳遞至接收端運(yùn)輸層； .4. 2)接收端運(yùn)輸層根據(jù)UDP協(xié)議將報(bào)文頭數(shù)據(jù)去除，并取出信息數(shù)據(jù)后傳遞至接收端應(yīng)用層； .4. 3)接收端應(yīng)用層的CRC模塊用以校驗(yàn)接收到的獨(dú)立數(shù)據(jù)包是否損壞或不完整，若數(shù)據(jù)包損壞或不完整，將數(shù)據(jù)包進(jìn)行刪除，若數(shù)據(jù)包完整且正確，則將完整且正確的數(shù)據(jù)包發(fā)送至Raptor碼解碼器； . 4.4)接收端應(yīng)用層Raptor譯碼器從等同的刪除信道中接收到前后無(wú)關(guān)聯(lián)、先后無(wú)次序的獨(dú)立數(shù)據(jù)包，若接收到的數(shù)據(jù)包數(shù)量大于原數(shù)據(jù)包數(shù)量，Raptor譯碼器譯碼結(jié)束；若超過(guò)一定時(shí)限，Raptor碼譯碼器仍未接收到足夠多的編碼數(shù)據(jù)包，根據(jù)事先設(shè)置向發(fā)送端發(fā)出繼續(xù)發(fā)送指示或者提醒用戶進(jìn)行下一步動(dòng)作的選擇。
5.一種即時(shí)通信工具在線文件發(fā)送接收方法，其特征在于，包括權(quán)利要求I至3任意一項(xiàng)一種即時(shí)通信工具在線文件發(fā)送方法和權(quán)利要求4 一種即時(shí)通信工具在線文件接收方法。
6.一種即時(shí)通信工具在線文件發(fā)送裝置，其特征在于，包括順序連接的發(fā)送端應(yīng)用層、發(fā)送端運(yùn)輸層和發(fā)送端物理層；所述發(fā)送端應(yīng)用層包括順序連接的打包封裝模塊、Raptor編碼模塊和CRC編碼模塊，打包封裝模塊用于將待發(fā)送文件數(shù)據(jù)進(jìn)行打包封裝成若干個(gè)數(shù)據(jù)包,Raptor編碼模塊用于Raptor碼編碼,CRC編碼模塊用于加載循環(huán)冗余碼CRC ;所述發(fā)送端運(yùn)輸層包括UDP協(xié)議模塊，UDP協(xié)議模塊用于將數(shù)據(jù)包進(jìn)行UDP協(xié)議轉(zhuǎn)換；所述發(fā)送端物理層包括順序連接的物理層編碼模塊和物理層調(diào)制模塊，物理層編碼模塊用于對(duì)數(shù)據(jù)包進(jìn)行信道編碼，物理層調(diào)制模塊用于對(duì)信道編碼后的數(shù)據(jù)進(jìn)行信道調(diào)制。
7.—種即時(shí)通信工具在線文件接收裝置，發(fā)端應(yīng)用層Raptor編碼器和收端應(yīng)用層Raptor譯碼器之間所有模塊，為具有一定丟包率的刪除信道，其特征在于，包括順序連接的接收端物理層、接收端運(yùn)輸層和接收端應(yīng)用層；所述接收端物理層包括順序連接的物理層解調(diào)模塊和物理層譯碼模塊，物理層解調(diào)模塊用于對(duì)數(shù)據(jù)包進(jìn)行信道解調(diào)，物理層譯碼模塊用于對(duì)信道解調(diào)后的數(shù)據(jù)進(jìn)行信道譯碼；所述接收端運(yùn)輸層包括UDP協(xié)議模塊，UDP協(xié)議模塊用于根據(jù)UDP協(xié)議將報(bào)文頭數(shù)據(jù)去除，并取出信息數(shù)據(jù)后傳遞至接收端應(yīng)用層；所述接收端應(yīng)用層包括順序連接的CRC校驗(yàn)?zāi)K、刪除模塊、Raptor譯碼器模塊和Raptor譯碼模塊，CRC校驗(yàn)?zāi)K用于檢測(cè)接收到的獨(dú)立數(shù)據(jù)包是否完整且正確，若數(shù)據(jù)包損壞或者不完整，送入刪除模塊將數(shù)據(jù)包進(jìn)行刪除，若數(shù)據(jù)包完整且正確，將完整且正確的數(shù)據(jù)包再分包發(fā)送至Raptor碼譯碼器模塊進(jìn)行譯碼；Rapt0r譯碼模塊用于判斷接收到的數(shù)據(jù)包數(shù)量和譯碼，完成等同刪除信道條件下原發(fā)送文件的恢復(fù)，若Raptor譯碼器模塊接收到完整且正確的數(shù)據(jù)包數(shù)量大于原數(shù)據(jù)包數(shù)量，譯碼結(jié)束；若超過(guò)一定時(shí)限，Raptor碼譯碼器仍未接收到足夠多完整且正確的編碼數(shù)據(jù)包，根據(jù)事先設(shè)置向發(fā)端發(fā)出繼續(xù)發(fā)送指示或者提醒用戶進(jìn)行下一步動(dòng)作的選擇。
8.—種即時(shí)通信工具在線文件發(fā)送接收系統(tǒng)，其特征在于，包括權(quán)利要求6所述的一種即時(shí)通信工具在線文件發(fā)送裝置、權(quán)利要求7所述的一種即時(shí)通信工具在線文件接收裝置以及連接它們的網(wǎng)絡(luò)。
全文摘要
本發(fā)明公開了一種即時(shí)通信工具在線文件發(fā)送、接收方法及裝置，發(fā)端應(yīng)用層Raptor編碼器和收端應(yīng)用層Raptor譯碼器之間所有模塊，為具有一定丟包率的刪除信道，該發(fā)送方法包括以下步驟1.1)將待發(fā)送文件數(shù)據(jù)進(jìn)行打包封裝成若干個(gè)數(shù)據(jù)包，在發(fā)送應(yīng)用層以數(shù)據(jù)包為單位進(jìn)行Raptor碼編碼，并加載循環(huán)冗余碼CRC后傳遞至發(fā)送端運(yùn)輸層；1.2)運(yùn)輸層采用UDP協(xié)議轉(zhuǎn)換后傳遞至物理層；1.3)物理層對(duì)數(shù)據(jù)包進(jìn)行信道編碼與調(diào)制后傳遞至網(wǎng)絡(luò)信道。本發(fā)明還公開了了一種即時(shí)通信工具在線文件接收方法、一種即時(shí)通信工具在線文件發(fā)送接收方法及發(fā)送、接收裝置及系統(tǒng)。本發(fā)明較QQ等即時(shí)通信工具的在線文件傳輸速度提高30%或以上。
文檔編號(hào)H04L12/58GK102938726SQ20121047210
公開日2013年2月20日 申請(qǐng)日期2012年11月20日 優(yōu)先權(quán)日2012年11月20日
發(fā)明者張偉, 單冬, 張春明, 馮錫生 申請(qǐng)人:北京交大微聯(lián)科技有限公司