數(shù)據(jù)包組播技術(shù)在廣播教學(xué)中的應(yīng)用

李香云, 葛 華

(1. 安徽科技學(xué)院 計(jì)算機(jī)系, 安徽 鳳陽(yáng), 233100; 2. 安徽科技學(xué)院 計(jì)算中心, 安徽 鳳陽(yáng), 233100)

數(shù)據(jù)包組播技術(shù)在廣播教學(xué)中的應(yīng)用

李香云1, 葛 華2

(1. 安徽科技學(xué)院 計(jì)算機(jī)系, 安徽 鳳陽(yáng), 233100; 2. 安徽科技學(xué)院 計(jì)算中心, 安徽 鳳陽(yáng), 233100)

針對(duì)目前流行的文件傳輸技術(shù)的不足, 提出采用組播模式和UDP協(xié)議實(shí)現(xiàn)文件傳輸. 并分析了UDP協(xié)議實(shí)現(xiàn)文件傳輸時(shí)的可靠性、有序性等方面的問(wèn)題. 并從數(shù)據(jù)拆分、數(shù)據(jù)組包、數(shù)據(jù)有序和數(shù)據(jù)重傳4個(gè)方面闡述其設(shè)計(jì)方法和設(shè)計(jì)過(guò)程.

組播; 數(shù)據(jù)拆包; 數(shù)據(jù)重傳

文件快速傳輸在網(wǎng)絡(luò)中得到廣泛應(yīng)用. 在多媒體網(wǎng)絡(luò)教室軟件中, 文件快速傳輸尤為重要, 不僅要保證文件傳輸?shù)姆€(wěn)定性和正確性, 還要考慮大文件傳輸時(shí)文件包拆分、文件包差錯(cuò)校驗(yàn)、文件包重傳、文件傳輸可靠性[1]等問(wèn)題, 并運(yùn)用UDP實(shí)現(xiàn)文件廣播傳輸和文件包拆分傳輸.

1 系統(tǒng)設(shè)計(jì)思想

文件傳輸技術(shù)在廣播教學(xué)中的應(yīng)用主要從兩個(gè)方面考慮, 首先是通訊模式的選擇, 然后是傳輸協(xié)議的選擇. 為了提高文件的傳輸應(yīng)采用組播技術(shù). UDP協(xié)議不提供數(shù)據(jù)傳送的保證機(jī)制, 從發(fā)送方到接收方的傳遞過(guò)程中出現(xiàn)數(shù)據(jù)報(bào)的丟失, 協(xié)議本身并不能做出任何檢測(cè)或提示, 也不進(jìn)行恢復(fù). 所以要提高UDP協(xié)議的可靠性與安全性[2-4], 就必須增加差錯(cuò)處理、有序保證和數(shù)據(jù)重傳機(jī)制, 通過(guò)增加差錯(cuò)處理機(jī)制, 使得數(shù)據(jù)報(bào)在傳輸過(guò)程中出錯(cuò)、或者丟失后能馬上檢測(cè)出來(lái)并被迅速地重傳.

1.1 數(shù)據(jù)拆包機(jī)制

考慮UDP協(xié)議網(wǎng)絡(luò)傳輸[5-6]單包傳送的最大數(shù)據(jù)為1 024字節(jié), 當(dāng)我們需要傳送的數(shù)據(jù)超過(guò)1 024字節(jié)時(shí), 只能將其拆分成小于1 024的數(shù)據(jù)包分別進(jìn)行傳送. 數(shù)據(jù)報(bào)報(bào)頭包含有文件類型和序列號(hào)的信息, 所以實(shí)際的用戶數(shù)據(jù)設(shè)計(jì)大小為1 000字節(jié). 當(dāng)應(yīng)用層需要傳送的數(shù)據(jù)超過(guò)1 000字節(jié)時(shí), 拆包機(jī)制開始執(zhí)行.它將原始數(shù)據(jù)拆分成 1 000字節(jié)大小的數(shù)據(jù)塊, 然后為每包數(shù)據(jù)加上文件類型和序列號(hào)信息. 這樣方便客戶端在接收到數(shù)據(jù)包后的組包機(jī)制的實(shí)施. 比如將文件名和文件長(zhǎng)度等信息作為第一個(gè)發(fā)送的數(shù)據(jù)包, 設(shè)置文件類型為 HEAD, 序列號(hào)為 0, 數(shù)據(jù)為文件長(zhǎng)度和文件名; 之后開始拆分原始數(shù)據(jù), 設(shè)置文件類型為DATA, 序列號(hào)從1開始加1遞增, 數(shù)據(jù)為1 000字節(jié)的實(shí)際數(shù)據(jù); 最后拆分成的是文件尾部, 設(shè)置文件類型為TAIL, 序列號(hào)為正常遞增后的序列號(hào), 數(shù)據(jù)為原始數(shù)據(jù)最后剩余下的字節(jié)數(shù).

1.2 數(shù)據(jù)組包及有序機(jī)制

當(dāng)服務(wù)器端傳送的數(shù)據(jù)大于 1 000字節(jié)時(shí), 在服務(wù)器端發(fā)送前會(huì)進(jìn)行拆包機(jī)制, 于是當(dāng)客戶端接收到服務(wù)器端發(fā)送來(lái)的拆分后的數(shù)據(jù)包時(shí), 需要進(jìn)行組包. 客戶端接收到數(shù)據(jù)后, 會(huì)對(duì)數(shù)據(jù)進(jìn)行組包, 這樣就可以實(shí)現(xiàn)較大數(shù)據(jù)量的傳輸, 組包的過(guò)程也就是保證數(shù)據(jù)有序的過(guò)程.

在網(wǎng)絡(luò)不穩(wěn)定的情況下, UDP數(shù)據(jù)包在傳送過(guò)程中有可能出現(xiàn)亂序問(wèn)題, 所以要想保證數(shù)據(jù)的順序是完全正確的, 就必須保證每一個(gè)拆分后的數(shù)據(jù)包在傳送過(guò)程中是按順序到達(dá)的. 有序機(jī)制是通過(guò)檢測(cè)接收到的數(shù)據(jù)包的序列號(hào)來(lái)實(shí)現(xiàn)的, 如果接收到的序列號(hào)是期望接收的序列號(hào), 則將此包存入等待寫入磁盤鏈表; 如果不是, 在接收此包并存入等待寫入磁盤鏈表時(shí)服務(wù)器端會(huì)同時(shí)發(fā)出包含有期望的數(shù)據(jù)包的序列號(hào)的重傳請(qǐng)求. 當(dāng)?shù)却龑懭氪疟P鏈表中有數(shù)據(jù)時(shí), 就啟動(dòng)寫入磁盤線程將鏈表中的數(shù)據(jù)寫入到磁盤中. 如果是正確接收到的數(shù)據(jù), 則一個(gè)一個(gè)寫入, 并在寫完一個(gè)數(shù)據(jù)包后將等待寫入磁盤鏈表中的此包清除; 如果寫入的是請(qǐng)求重傳后收到的的重傳數(shù)據(jù)包, 則需要根據(jù)包的序列號(hào)將文件的指針指向此包應(yīng)該寫入的位置,正確寫入, 之后也將等待寫入磁盤隊(duì)列中的此包清除. 這樣就可以保證接收端的數(shù)據(jù)包的有序性.

1.3 數(shù)據(jù)重發(fā)機(jī)制

UDP協(xié)議不提供錯(cuò)誤檢測(cè)機(jī)制, 自然也不提供錯(cuò)誤數(shù)據(jù)重傳服務(wù), 所以必須提供一套數(shù)據(jù)重傳機(jī)制使數(shù)據(jù)在出錯(cuò)后可以及時(shí)地修正, 保證數(shù)據(jù)可以可靠地到達(dá)目的地, 數(shù)據(jù)重傳機(jī)制包括兩種情況, 第一種情況是客戶端發(fā)送的重傳請(qǐng)求的數(shù)據(jù)包在服務(wù)器端的等待重傳鏈表中, 則從等待重傳鏈表中找到該包并立即重傳到客戶端. 第二種情況是客戶端發(fā)送的重傳請(qǐng)求的數(shù)據(jù)包不在服務(wù)器端的等待重傳鏈表中, 服務(wù)器端則向客戶端發(fā)送包含有此數(shù)據(jù)包序列號(hào)的等待最后重傳消息, 最后調(diào)用統(tǒng)一重傳函數(shù), 統(tǒng)一的重傳這些數(shù)據(jù)包.

1.4 機(jī)制的合并

上述的幾種機(jī)制只有整合在一起才可以保證 UDP數(shù)據(jù)報(bào)在傳輸過(guò)程中是安全可靠的. 整合的基本設(shè)計(jì)思路是這樣的: 在服務(wù)器端程序中創(chuàng)建了一個(gè)線程, 該線程中的線程函數(shù)負(fù)責(zé)讀取數(shù)據(jù)并根據(jù)數(shù)據(jù)的大小決定是否拆包, 然后調(diào)用相應(yīng)的發(fā)送函數(shù)進(jìn)行發(fā)送, 發(fā)送后立即將發(fā)送過(guò)的數(shù)據(jù)保存入一個(gè)等待重傳鏈表, 并立即啟動(dòng)接收反饋線程, 等待接收客戶端的文件類型為NACK反饋數(shù)據(jù). 若收到客戶端的文件類型為NACK的重傳請(qǐng)求, 則進(jìn)入等待重傳鏈表尋找此數(shù)據(jù)包, 如果找到此數(shù)據(jù)包, 調(diào)用相應(yīng)的重傳函數(shù)進(jìn)行重新發(fā)送數(shù)據(jù), 如果沒(méi)有在重傳鏈表中找到需要重傳的數(shù)據(jù)包, 服務(wù)器端向客戶端發(fā)送等待最后重傳消息,并在最后調(diào)用統(tǒng)一重傳函數(shù)重傳數(shù)據(jù). 在客戶端程序中創(chuàng)建了一個(gè)接收線程, 該線程中的線程函數(shù)負(fù)責(zé)接收數(shù)據(jù), 并將接收到的數(shù)據(jù)存入一個(gè)等待寫入磁盤鏈表中, 如果發(fā)現(xiàn)接收到的數(shù)據(jù)包不是期望的, 則在將此數(shù)據(jù)包存入等待寫入磁盤鏈表中后, 調(diào)用請(qǐng)求重傳函數(shù), 向服務(wù)器端發(fā)出重傳請(qǐng)求. 如果等待寫入磁盤鏈表中有數(shù)據(jù), 就啟動(dòng)寫入磁盤線程將鏈表中的數(shù)據(jù)寫入磁盤中. 在寫入磁盤的過(guò)程中實(shí)現(xiàn)了數(shù)據(jù)的組包及有序.

2 數(shù)據(jù)報(bào)報(bào)頭設(shè)計(jì)

數(shù)據(jù)報(bào)報(bào)頭應(yīng)該包含數(shù)據(jù)傳送過(guò)程中需要的基本信息, 本文用文件類型標(biāo)識(shí)傳送的是文件頭部信息,還是實(shí)際數(shù)據(jù)信息或是文件尾部信息. 用拆包序列號(hào)來(lái)滿足回傳請(qǐng)求及組包機(jī)制的實(shí)現(xiàn)需求, 最后要包括的就是實(shí)際傳送的數(shù)據(jù). 考慮到UDP數(shù)據(jù)包在網(wǎng)絡(luò)傳輸時(shí)最大字節(jié)的限制, 數(shù)據(jù)的實(shí)際內(nèi)容用了1 000字節(jié), 報(bào)報(bào)頭設(shè)計(jì)如圖1所示.數(shù)據(jù)報(bào)報(bào)頭的的結(jié)構(gòu)體設(shè)計(jì)如下:

圖1 數(shù)據(jù)報(bào)報(bào)頭設(shè)計(jì)圖

3 系統(tǒng)處理流程圖

3.1 服務(wù)器端發(fā)送線程

服務(wù)器端的發(fā)送線程先發(fā)送文件的頭部信息, 如果客戶端沒(méi)能正確的接收文件的頭部信息, 則繼續(xù)等待接收文件的頭部信息. 服務(wù)器端重新發(fā)送, 直到客戶端正確接收到文件的頭部信息為止. 接下來(lái)發(fā)送文件的正文信息, 發(fā)送后立即將發(fā)送過(guò)的數(shù)據(jù)保存入一個(gè)等待重傳鏈表. 如果某數(shù)據(jù)包未能正確接收, 服務(wù)器端會(huì)收到客戶端的帶有包的序列號(hào)的重傳請(qǐng)求. 服務(wù)器端接收到重傳請(qǐng)求后, 會(huì)先進(jìn)入等待重傳鏈表中尋找此包, 如果找到, 則調(diào)用重傳函數(shù)立即重傳此包. 如果沒(méi)有在重傳鏈表中找到此包, 則向客戶端發(fā)送等待統(tǒng)一最后重傳消息, 等所有數(shù)據(jù)全部發(fā)送完后, 再調(diào)用統(tǒng)一重傳函數(shù)將沒(méi)有正確接收的包重新發(fā)送,服務(wù)器端的發(fā)送線程如圖2所示.

3.2 客戶端接收線程

客戶端的接收線程先接收服務(wù)器端發(fā)送來(lái)的文件的頭部信息, 如果沒(méi)有正確接收文件的頭部信息, 則一直不停的接收服務(wù)器端發(fā)送來(lái)的頭部信息, 直到正確接收到為止. 然后開始接收服務(wù)器端發(fā)送來(lái)的每包的數(shù)據(jù), 接收到數(shù)據(jù)后先將接收到的數(shù)據(jù)存入一個(gè)等待寫入磁盤鏈表, 如果發(fā)現(xiàn)接收到的包的序列號(hào)與期望接收到的包的序列號(hào)不同, 即說(shuō)明接收到的包不是期望接收的包, 則先將此包保存入等待寫入磁盤鏈表,同時(shí)向服務(wù)器端發(fā)送帶有期望包序列號(hào)的重傳請(qǐng)求. 如果接收到服務(wù)器端發(fā)送的帶有重傳標(biāo)志RSED的包,先判斷此包是否是期望重傳的包, 如果確實(shí)請(qǐng)求過(guò)重傳此包, 則接收此包, 并存入等待寫入磁盤鏈表. 如果沒(méi)有請(qǐng)求重傳過(guò)此包, 則丟棄. 最后接收服務(wù)器端傳送的文件類型為TAIL的包, 其處理方式與文件類型為DATA的方式相同. 客戶端接收線程的流程圖如圖3所示.

圖2 服務(wù)器端發(fā)送線程流程圖

圖3 客戶端接收線程流程圖

3.3 服務(wù)器端的接收反饋線程和重傳函數(shù)流程圖

由于采用UDP傳送數(shù)據(jù)時(shí), 會(huì)有丟包、亂序等數(shù)據(jù)差錯(cuò)問(wèn)題, 所以服務(wù)器端在發(fā)送數(shù)據(jù)后立即調(diào)用接收反饋線程, 準(zhǔn)備接收客戶端發(fā)送來(lái)的重傳消息. 如果客戶端有重傳請(qǐng)求, 接收反饋線程接收此請(qǐng)求. 首先對(duì)接收到的重傳請(qǐng)求的文件類型位進(jìn)行判斷, 如果文件類型設(shè)置的是 NACK, 說(shuō)明此數(shù)據(jù)是客戶端的重傳請(qǐng)求. 則調(diào)用重傳函數(shù)重新傳送客戶端請(qǐng)求的包. 如果不是 NACK, 則服務(wù)器端的接收反饋線程不對(duì)接收到的此消息做出響應(yīng), 而是直接將此消息丟棄. 接收反饋線程的執(zhí)行流程如圖4所示.

服務(wù)器端的重傳函數(shù)首先判斷重傳NUM是否大于零以決定是否有需要重傳的數(shù)據(jù)包. 如果重傳NUM大于零, 說(shuō)明有需要重傳的數(shù)據(jù), 則進(jìn)入服務(wù)器端保存重傳數(shù)據(jù)的重傳鏈表, 在此隊(duì)列中尋找序列號(hào)等于請(qǐng)求重傳的序列號(hào)的包, 如果在重傳隊(duì)列中找到此包, 則立即重傳此包, 如果沒(méi)有找到此包, 就向客戶端發(fā)送等待最后統(tǒng)一重傳消息, 等待最后統(tǒng)一重傳這些數(shù)據(jù). 重傳結(jié)束后, 再次判斷是否有需要重傳的包.依次傳送, 直至全部傳送完需要重傳的包. 重傳函數(shù)的流程圖如圖5所示:

圖4 服務(wù)器端的接收反饋線程

圖5 服務(wù)器端的重傳函數(shù)流程圖

3.4 客戶端的寫入線程

客戶端接收到數(shù)據(jù)后, 就啟動(dòng)寫入線程將數(shù)據(jù)寫入到磁盤中. 寫入的數(shù)據(jù)分為兩種類型, 一種是正確接收到的數(shù)據(jù)包, 一種是接收到的重傳的數(shù)據(jù)包.

對(duì)于正確接收到的數(shù)據(jù)包, 又分為文件類型為DATA的數(shù)據(jù)包和文件類型為TAIL的尾部數(shù)據(jù)包. 在寫入文件類型為 DATA的數(shù)據(jù)包時(shí), 先判斷等待寫入鏈表是否為空, 如果鏈表不為空, 說(shuō)明鏈表中有數(shù)據(jù)可以寫入到磁盤中, 再判斷此時(shí)是否已經(jīng)到等待寫入鏈表的尾部, 若沒(méi)有到鏈表的尾部, 則取出鏈表中的數(shù)據(jù), 向磁盤中寫入1 000字節(jié)大小的數(shù)據(jù). 然后刪除等待寫入鏈表中的此數(shù)據(jù)包, 即從鏈表的頭部刪除, 接著判斷等待寫入鏈表中的下一個(gè)數(shù)據(jù)包, 如上依次寫入磁盤, 直到等待寫入鏈表為空或者到達(dá)鏈表的尾部.在寫入文件類型為TAIL的數(shù)據(jù)包時(shí), 取出鏈表中的數(shù)據(jù), 向磁盤中寫入最后一包大小的數(shù)據(jù), 然后從等待寫入鏈表中刪除此數(shù)據(jù)包. 執(zhí)行流程如圖6所示.

對(duì)于接收到的文件類型為 RSED的包, 在重傳鏈表不為空并且沒(méi)有到達(dá)鏈表尾部的情況下, 還需通過(guò)包的序列號(hào)定位此包在磁盤中的正確位置, 找到此數(shù)據(jù)包在磁盤中的正確位置后, 將此包的數(shù)據(jù)寫入到磁盤中, 刪除重傳鏈表中此數(shù)據(jù)包, 然后再次判斷重傳鏈表是否為空或已經(jīng)到達(dá)鏈表的尾部, 如果為空或已到達(dá)尾部, 則結(jié)束此次寫入操作. 執(zhí)行流程如圖7所示.

3.5 發(fā)送線程代碼

因編碼較多這里只給出發(fā)送數(shù)據(jù)線程代碼, 其編碼如下:

圖6 客戶端接收正常數(shù)據(jù)的寫入流程圖

圖7 客戶端接收重傳數(shù)據(jù)的寫入流程圖

4 實(shí)驗(yàn)結(jié)果

在實(shí)驗(yàn)中, 我們?cè)谝粋€(gè)80臺(tái)計(jì)算機(jī)實(shí)驗(yàn)室利用組播技術(shù)文件傳輸程序, 將一個(gè)100 MB文件分發(fā)到實(shí)驗(yàn)室的其他機(jī)器中, 實(shí)驗(yàn)結(jié)果表明: 一個(gè)100 MB的文件無(wú)差錯(cuò)快速傳輸, 耗時(shí)為12秒.

5 小結(jié)

本文介紹了文件傳輸技術(shù)在廣播教學(xué)中的應(yīng)用, 使用組播和UDP協(xié)議針對(duì)UDP的無(wú)連接、不可靠等方面進(jìn)行了改進(jìn), 采用數(shù)據(jù)拆包、數(shù)據(jù)組包、數(shù)據(jù)有序控制和數(shù)據(jù)重傳等機(jī)制解決此問(wèn)題, 使得文件在局域網(wǎng)內(nèi)可以有序的、可靠的進(jìn)行傳輸, 滿足了廣播教學(xué)的需求. 本文所介紹技術(shù)雖滿足了教師的多媒體教學(xué)之需, 但還存在一些不足, 比如文件傳輸?shù)乃俣确矫孢€可以有所提高, 以及多文件傳輸[7-9]在具體實(shí)現(xiàn)中采用超時(shí)機(jī)制. 可以在文件的每個(gè)數(shù)據(jù)包發(fā)送后設(shè)置超時(shí), 當(dāng)超時(shí)發(fā)生時(shí), 自動(dòng)重傳超時(shí)的數(shù)據(jù)包, 以解決丟包問(wèn)題, 但由于超時(shí)時(shí)間的設(shè)置與網(wǎng)絡(luò)有密切的關(guān)系, 具體的參數(shù)設(shè)置需要通過(guò)針對(duì)具體的網(wǎng)絡(luò)進(jìn)行估算與計(jì)算, 而且需要有一定的經(jīng)驗(yàn), 可以說(shuō)是在某種程度上是一個(gè)經(jīng)驗(yàn)值, 并且有一定的復(fù)雜性和難度,需要進(jìn)一步進(jìn)行研究.

[1] 李國(guó), 鞏光志, 王冬冬. 一種提高UDP可靠性的數(shù)據(jù)傳輸方法研究[J]. 中國(guó)民航大學(xué)學(xué)報(bào), 2012(1): 41-45.

[2] 尹然然. 基于UDP協(xié)議的可靠性改進(jìn)協(xié)議[J]. 電腦知識(shí)與技術(shù), 2010(16): 4379-4380.

[3] 王大羽, 陳瑩. 基于UDP的協(xié)議可靠性傳輸設(shè)計(jì)與實(shí)現(xiàn)[J]. 福建電腦, 2009(8): 132-133.

[4] 王繼剛, 顧國(guó)昌, 徐立峰, 等. 可靠UDP數(shù)據(jù)傳輸協(xié)議的研究與設(shè)計(jì)[J]. 計(jì)算機(jī)工程與應(yīng)用, 2006(15): 113-116.

[5] 李永勝, 黃蘭紅, 劉紅軍. 基于UDP協(xié)議的多文件傳輸[J]. 廣西民族大學(xué)學(xué)報(bào): 自然科學(xué)版, 2007(2): 68-71, 93.

[6] 曹婧華, 趙飛, 冉彥中. 局域網(wǎng)文件傳輸?shù)腄elphi編程實(shí)現(xiàn)[J]. 長(zhǎng)春師范學(xué)院學(xué)報(bào), 2011(2): 40-42.

[7] 唐彰國(guó), 鐘明全, 李煥洲, 等. 基于數(shù)據(jù)流的啟發(fā)式文件傳輸識(shí)別系統(tǒng)設(shè)計(jì)[J]. 計(jì)算機(jī)工程與設(shè)計(jì), 2011(9): 2929-2933, 2949.

[8] 董淑松, 康慕寧. 基于可靠組播文件傳輸協(xié)議的設(shè)計(jì)與分析[J]. 科學(xué)技術(shù)與工程, 2010(9): 2195-2198, 2206.

[9] 祝紅琴, 王芳, 黎智軍. 基于文件傳輸中文件損壞的檢測(cè)和恢復(fù)辦法[J]. 硅谷, 2010(20): 188.

(責(zé)任編校: 譚長(zhǎng)貴)

DataPacket file multicasting technology in broadcasting teaching application

LI Xiang-yun1, GE Hua2
(1. The Computer center, Anhui Scrience and Technology University, Fengyang 233100, China; 2. The Department of computer, Anhui Scrience and Technology University, Fengyang 233100, China)

In view of current popular file transmission technology insufficiency, this article provided a method which realize process to carry on reliable and fast multiple file transmission by the multicast mode and UDP protocol file transfer, and UDP protocol file transfer reliability, ordering and other aspects of the problem. And its design methods and design process were discussed from four aspects: the data, the data group packet, data orderly and retransmission.

Multicast; Data unpacking; Data retransmission

TP 317

1672-6146(2012)02-0086-06

10.3969/j.issn.1672-6146.2012.02.021

2012-05-02

安徽科技學(xué)院青年科學(xué)研究基金(ZRC2011273), 安徽科技學(xué)院引進(jìn)人才基金資助(ZRC2010255).

李香云(1982-), 助理實(shí)驗(yàn)師, 碩士生, 主研領(lǐng)域: 信息管理系統(tǒng)、實(shí)驗(yàn)室管理、計(jì)算機(jī)網(wǎng)絡(luò).

E-mail:bluecomputing@126.com