基于UDP的導(dǎo)播系統(tǒng)文件傳輸模塊設(shè)計(jì)

李岳

（91941 部隊(duì)45 分隊(duì)，遼寧 葫蘆島125000）

目前市場上的導(dǎo)播系統(tǒng)多數(shù)具備聯(lián)網(wǎng)控制功能，從最開始的單一形態(tài)過渡到現(xiàn)階段的智能形態(tài)，實(shí)現(xiàn)了本地控制向聯(lián)網(wǎng)導(dǎo)播的轉(zhuǎn)變[1]。文件傳輸成為導(dǎo)播系統(tǒng)的基本通信功能，隨著網(wǎng)絡(luò)技術(shù)的更新，傳統(tǒng)文件傳輸方式已經(jīng)不能適應(yīng)網(wǎng)絡(luò)化時(shí)代的需求。目前大多數(shù)的導(dǎo)播系統(tǒng)采用的網(wǎng)絡(luò)協(xié)議占用CPU 內(nèi)存較高，文件發(fā)送傳輸速度較慢，對于視頻文件更需要很高的帶寬要求，為系統(tǒng)運(yùn)行增加的負(fù)擔(dān)，需要針對此問題進(jìn)行改善。UDP 協(xié)議具有無連接的特點(diǎn)，可降低系統(tǒng)開銷，加快傳輸速度[2]。因此本文基于UDP 設(shè)計(jì)導(dǎo)播系統(tǒng)文件傳輸模塊，提高文件傳輸效率，使導(dǎo)播系統(tǒng)更好地適應(yīng)復(fù)雜網(wǎng)絡(luò)環(huán)境變化。

1 導(dǎo)播系統(tǒng)文件傳輸模塊設(shè)計(jì)

1.1 接收傳輸服務(wù)的文件配置請求

文件傳輸服務(wù)通常是對服務(wù)模塊的抽象化處理，將其功能獨(dú)立出來完成單獨(dú)服務(wù)，方便系統(tǒng)對文件的調(diào)用。為確保文件傳輸模塊提供良好的傳輸方案，首先對接收系統(tǒng)傳輸服務(wù)的文件請求進(jìn)行設(shè)計(jì)，維護(hù)文件狀態(tài)。文件傳輸服務(wù)通過任務(wù)XML文件提供服務(wù)接口，與具體的語言無關(guān)，傳輸?shù)墓?jié)點(diǎn)不必建立直接的通信關(guān)聯(lián)，減少了不同節(jié)點(diǎn)間的耦合度，保證傳輸?shù)莫?dú)立性[3]。設(shè)計(jì)兩個(gè)目錄，一個(gè)目錄（T）用于存放程序指定任務(wù)，另一個(gè)目錄（R）存放傳輸服務(wù)的狀態(tài)和結(jié)果。外源程序在傳輸服務(wù)請求階段，生成任務(wù)XML 文件，文件名由字符串和時(shí)間構(gòu)成，用于描述傳輸文件位置和必要信息。監(jiān)控模塊動(dòng)態(tài)檢測T 目錄內(nèi)容，一旦檢測到傳輸任務(wù)，提取任務(wù)信息并啟動(dòng)傳輸，在R 目錄中記錄同名結(jié)果文件，并根據(jù)傳輸?shù)牟煌A段記錄文件狀態(tài)標(biāo)識。傳輸模塊通過文件配置請求，展現(xiàn)系統(tǒng)擁有的功能，而外源程序可將需求寫入文件配置請求中，導(dǎo)播系統(tǒng)通過配置請求獲知文件傳輸要求，進(jìn)行相應(yīng)的操作。文件配置請求功能作為傳輸服務(wù)和外源程序的接口，在保證二者獨(dú)立性的同時(shí)，實(shí)現(xiàn)了相互的連通，為后續(xù)文件數(shù)據(jù)的交換提供基礎(chǔ)。

1.2 基于UDP 的文件傳輸處理

文件傳輸處理主要是根據(jù)外源程序的請求，進(jìn)行文件數(shù)據(jù)的交換與傳輸?？傮w的功能主要包括三部分，首先是對各子模塊進(jìn)行中樞調(diào)度，其次在各子模塊與外部模塊間進(jìn)行數(shù)據(jù)接收和發(fā)送，最后對文件進(jìn)行傳輸調(diào)度處理。文件傳輸處理首先考慮對網(wǎng)絡(luò)傳輸協(xié)議的選取，本文選取UDP 協(xié)議負(fù)責(zé)文件數(shù)據(jù)的發(fā)送與接收。UDP 主要完成兩方面任務(wù)，一是發(fā)送接收數(shù)據(jù)，二是控制擁塞。發(fā)送窗口受接收端的反饋調(diào)節(jié)，在一個(gè)周期內(nèi)確認(rèn)數(shù)據(jù)包并將其發(fā)送至接收端，并將反饋結(jié)果傳回至發(fā)送端。UDP 啟動(dòng)時(shí)，設(shè)定其發(fā)送窗口的初始大小為2。在文件數(shù)據(jù)傳輸過程中，傳輸模塊接收到數(shù)據(jù)包，發(fā)送端調(diào)整發(fā)送窗口大小，可以表示為：

式（1）中，Cud表示發(fā)送后的更新窗口大??；Cpr表示更新前的窗口大??；P 表示確認(rèn)反饋的文件數(shù)據(jù)包數(shù)量。UDP 啟動(dòng)階段，數(shù)據(jù)包發(fā)送間隔幾乎為零，能夠充分利用帶寬資源快速啟動(dòng)，減少了其它協(xié)議反復(fù)進(jìn)入啟動(dòng)階段的時(shí)間，提高數(shù)據(jù)傳輸效率。提取發(fā)送和接收最大窗口的較小值，作為更新窗口的限制值，當(dāng)窗口達(dá)到限制值，說明啟動(dòng)階段結(jié)束，進(jìn)入擁塞控制階段。在控制階段，接收端能夠接收到發(fā)送的數(shù)據(jù)，說明帶寬存在可被利用空間，發(fā)送速率在固定時(shí)間間隔的增量，控制了文件傳輸?shù)男逝c穩(wěn)定性，有利于網(wǎng)絡(luò)的平衡與穩(wěn)定性。在數(shù)據(jù)持續(xù)發(fā)送階段，如果收到了接收端的反饋，則說明網(wǎng)絡(luò)開始出現(xiàn)擁塞，此時(shí)發(fā)送端降低速率，緩解鏈路擁堵。其它協(xié)議多采用重置窗口大小的方式，或重新進(jìn)入啟動(dòng)階段，影響數(shù)據(jù)傳輸速率。而本文方法可通過速率的自動(dòng)調(diào)節(jié)變化，減緩網(wǎng)絡(luò)鏈路的飽和趨勢，為數(shù)據(jù)傳輸提供比較可靠的保障。

1.3 設(shè)置傳輸文件格式完成數(shù)據(jù)通信

文件傳輸過程中，需要對發(fā)送類和接收類文件提供必要的序列化自定義，設(shè)置文件格式和傳輸?shù)南鄳?yīng)參數(shù)。類前需要增加可序列化標(biāo)志，便于添加需要的參數(shù)。序列化是將狀態(tài)信息轉(zhuǎn)化為可存儲和可傳輸?shù)倪^程，方便保存和傳輸數(shù)據(jù)，增加傳輸協(xié)議參數(shù)的靈活性。序列化標(biāo)志主要定義了文件三個(gè)公共屬性，包括加密值、數(shù)據(jù)包和序列號，具體包含了加密值、文件名、數(shù)據(jù)包數(shù)量、長度和大小。在發(fā)送階段觸發(fā)相關(guān)事件，接收階段實(shí)現(xiàn)參數(shù)的傳遞，此時(shí)需要考慮數(shù)據(jù)丟包和超時(shí)重發(fā)的問題。對于數(shù)據(jù)丟包檢測，定義屬性為ReFileList，類型為＜序列號，接收標(biāo)識＞，初始化全部為未被接受狀態(tài)。在此基礎(chǔ)上定義計(jì)時(shí)器類對象，判斷是否傳輸超時(shí)。當(dāng)接收方同意文件時(shí)，啟動(dòng)計(jì)時(shí)器，開始記錄傳輸時(shí)間。觸發(fā)超時(shí)事件，要求重新發(fā)送文件，此時(shí)在＜序列號，接收標(biāo)識＞列表中進(jìn)行查詢。文件接收時(shí)，首先創(chuàng)建臨時(shí)文件，對其進(jìn)行安全文件包裝，并初始化列表。文件為接收狀態(tài)，不進(jìn)行讀操作并返回；否則，接收文件數(shù)量增加1。在緩沖區(qū)進(jìn)行異步讀寫操作，進(jìn)入文件調(diào)回。文件傳輸完畢后，進(jìn)行校驗(yàn)，調(diào)用靜態(tài)加密值，加密值相同則為同一文件，結(jié)束寫文件操作。文件接收完畢后，釋放使用資源，以此完成數(shù)據(jù)通信。

2 實(shí)驗(yàn)結(jié)果與分析

為檢驗(yàn)本文設(shè)計(jì)的文件傳輸模塊的應(yīng)用效果，與傳統(tǒng)導(dǎo)播系統(tǒng)的文件傳輸模塊進(jìn)行對比。傳統(tǒng)的導(dǎo)播系統(tǒng)主要采用TCP和RTP 協(xié)議，將采用TCP 協(xié)議的傳輸模塊設(shè)置為傳統(tǒng)模塊1，RTP 協(xié)議設(shè)定為傳統(tǒng)模塊2，測試文件傳輸效率。

2.1 基本傳輸功能測試

首先對文件基本傳輸功能進(jìn)行測試。從單個(gè)文件傳輸時(shí)間和任務(wù)并發(fā)度兩個(gè)方面，測試文件傳輸性能。

隨單個(gè)文件增大，文件傳輸時(shí)間相應(yīng)增加，這是由于受到網(wǎng)絡(luò)帶寬的限制，文件傳輸速度隨文件增大而降低。由于本文模塊選擇的傳輸協(xié)議具有高帶寬優(yōu)點(diǎn)，可進(jìn)行路徑選擇，因此本文設(shè)計(jì)方法的傳輸時(shí)間明顯小于傳統(tǒng)方法，具有一定通信優(yōu)勢。

任務(wù)并發(fā)度主要由導(dǎo)播系統(tǒng)的列隊(duì)大小決定，直接影響到單個(gè)文件的傳輸速度。根據(jù)表1 的測試結(jié)果，并發(fā)任務(wù)量的增加，文件傳輸時(shí)間增大，由于系統(tǒng)總帶寬固定，因此增加文件傳輸任務(wù)量后，傳輸速度相應(yīng)降低，消耗的傳輸時(shí)間增加。本文模塊的傳輸時(shí)間隨文件數(shù)量增加的幅度小于傳統(tǒng)模塊，能夠有效并發(fā)處理多個(gè)發(fā)送和接收任務(wù)。綜合上述基本文件傳輸功能的測試結(jié)果，本文設(shè)計(jì)的導(dǎo)播系統(tǒng)文件傳播模塊具有一定的穩(wěn)定性，能夠保證完整的文件傳輸。

2.2 文件傳輸效率測試

在檢驗(yàn)基本文件傳輸功能的基礎(chǔ)上，對導(dǎo)播系統(tǒng)文件傳輸效率進(jìn)行測試。采用文件傳輸時(shí)間和速度，作為衡量傳輸效率的指標(biāo)，分別測試不同客戶端條件下的傳輸效率。文件傳輸時(shí)間測試結(jié)果見表2，傳輸速度測試結(jié)果見表3。

表2 不同客戶端條件下文件傳輸時(shí)間測試結(jié)果

表3 不同客戶端條件下文件傳輸速度測試結(jié)果

根據(jù)表2 和表3 的測試結(jié)果，在單客戶端條件下，本文設(shè)計(jì)的文件傳輸模塊的傳輸時(shí)間低于傳統(tǒng)模塊，速度高于傳統(tǒng)模塊；在多客戶端條件下，本文傳輸時(shí)間和速度波動(dòng)較小，基本可保持在較高的水平，而傳統(tǒng)模塊的傳輸時(shí)間增加，速度明顯下降。由于本文設(shè)計(jì)模塊可同時(shí)對多客戶端傳輸文件，效率相對較高；而傳統(tǒng)模塊缺少組播功能，在多客戶端時(shí)需采用多線程的逐一傳送方式，傳輸效率相對較低。綜合上述實(shí)驗(yàn)結(jié)果，本文基于UDP 的導(dǎo)播系統(tǒng)文件傳輸模塊，可以實(shí)現(xiàn)基本的文件傳輸功能，與傳統(tǒng)方法相比，傳輸時(shí)間短速度快，因此具有較高的傳輸效率，可應(yīng)用于實(shí)際導(dǎo)播系統(tǒng)中。

結(jié)束語

本文設(shè)計(jì)的文件傳輸模塊雖然在一定程度上提高了傳輸效率，但還存在不足之處。后續(xù)應(yīng)針對文件傳輸?shù)陌踩赃M(jìn)行研究，為保證用戶的隱私安全，添加有效的驗(yàn)證機(jī)制，對文件傳輸進(jìn)行安全保護(hù)。