UDP文件傳輸?shù)脑O計與實現(xiàn)

1、實訓專題報告題 目： UDP文件傳輸系的設計 實訓名稱： 班 級： 學 號： 學生姓名： 指導教師： 哈爾濱工程大學2013年8月30日摘 要UDP(User Datagram Protocol)協(xié)議的全稱是用戶數(shù)據(jù)報協(xié)議，在網(wǎng)絡中它與TCP(Transmission Control Protocol)協(xié)議一樣用于處理數(shù)據(jù)包，是一種無連接的協(xié)議。UDP有不提供數(shù)據(jù)包分組、組裝和不能對數(shù)據(jù)包進行排序的缺點，也就是說，當報文發(fā)送之后，是無法得知其是否安全完整到達的。UDP用來支持那些需要在計算機之間傳輸數(shù)據(jù)的網(wǎng)絡應用。包括網(wǎng)絡視頻會議系統(tǒng)在內(nèi)的眾多的客戶-服務器模式的網(wǎng)絡應用都需要使用UDP協(xié)議1

2、。UDP協(xié)議從問世至今已經(jīng)被使用了很多年，雖然其最初的光彩已經(jīng)被一些類似協(xié)議所掩蓋，但是即使是在今天UDP仍然不失為一項非常實用和可行的網(wǎng)絡傳輸層協(xié)議。本文在應用現(xiàn)有的C語言應用開發(fā)知識基礎上，又應用了socket和多線程編程技術(shù)的有關(guān)知識。使用C語言以及標準庫函數(shù)，在Windows平臺上，開發(fā)基于UDP協(xié)議的文件傳輸系統(tǒng)。對UDP文件傳輸系統(tǒng)的調(diào)試結(jié)果顯示：UDP文件傳輸系統(tǒng)實現(xiàn)了文件在客戶端和服務端之間的發(fā)送和接收，傳輸過程中可顯示文件信息，在傳輸過程中可中斷傳輸，但暫時還不能保證完全不丟包。關(guān)鍵詞：文件傳輸；socket編程技術(shù)；基本功能當前的世界經(jīng)濟正在從工業(yè)經(jīng)濟向知識經(jīng)濟轉(zhuǎn)變，這種以

3、知識為基礎的經(jīng)濟有兩個重要的特點，就是信息化和全球化。而要實現(xiàn)信息化和全球化，就必須依靠完善的網(wǎng)絡。計算機網(wǎng)絡是核心，而信息的交流又是計算機網(wǎng)絡中非常重要的部分，因此UDP協(xié)議就占了很大比重。由于UDP不屬于連接型協(xié)議，因而具有資源消耗小，處理速度快的優(yōu)點，所以通常音頻、視頻和普通數(shù)據(jù)在傳送時使用UDP較多，比如我們聊天用的QQ所使用的就是UDP協(xié)議。雖然UDP是一個不可靠的協(xié)議，但它是分發(fā)信息的一個理想?yún)f(xié)議。UDP廣泛應用在多媒體應用中，例如Progressive Networks公司開發(fā)的RealAudio軟件，該軟件所使用的協(xié)議就是基于UDP之上的協(xié)議，大多數(shù)因特網(wǎng)電話軟件產(chǎn)品也都是基于

4、UDP協(xié)議的?；谝陨戏治?本文要涉及的UDP文件傳輸系統(tǒng)設計是一個具備基本功能的嵌入式系統(tǒng)。1需求分析與系統(tǒng)總體設計1.1 需求分析基于UDP文件傳輸系統(tǒng)應包含以下功能：在服務端和客戶端實現(xiàn)基本的文件傳輸；在文件傳輸過程中顯示文件的信息；在文件傳輸過程中可以取消文件傳輸過程。具體目標如下：（1）在客戶端主機上能讀取一個txt文件與服務端主機進行傳輸。（2）在傳輸過程中能顯示文件信息，如文件名、保存路徑、文件大小、傳輸進度等。（3）傳輸過程中可以選擇中斷文件傳輸過程。（4）本程序中要保證文件在傳輸?shù)倪^程中實現(xiàn)完整傳輸，即不丟包。（5）界面盡量簡潔大方，程序運行時不要出現(xiàn)異常。本章主要討論了系統(tǒng)

5、的需求分析，從用戶角度分析系統(tǒng)整體要實現(xiàn)的功能。需求分析表如表1.1所示。1.2 系統(tǒng)總體設計本軟件是為了使文件傳輸變得更加方便、快捷和安全，所以設計難點是在傳輸控制方面，對于本軟件來說，用戶界面設計則不是那么重要。程序設計過程主要是通過Winsock控件進行UDP文件傳輸。分別在發(fā)送端和接收端建立控件Winsock，經(jīng)過對Winsock控件程序的寫入，然后通過端口號和IP地址的綁定來建立聯(lián)系，直接可以傳送文件，而且能準確地發(fā)送和接收。UDP文件傳輸系統(tǒng)主要是在客戶端與服務端之間進行文件的傳輸，首先在一臺計算機中選取一個文件，通過輸入文件所在位置來實現(xiàn)的該文件的讀寫，然后進行分包處理以便于后續(xù)

6、的文件傳送。在文件傳輸過程中要求顯示文件信息，如文件名、保存路徑、文件大小、傳輸進度等，使用戶清楚文件傳輸?shù)那闆r以便選擇繼續(xù)或取消，所以該軟件還具備隨時中斷文件傳輸?shù)墓δ?。待文件發(fā)送后，另一臺計算機要求能夠接收該文件并讀取、保存在計算機內(nèi)。因此，開發(fā)人員需要編寫兩方面的代碼，即服務端代碼和客戶端代碼，然后再將這兩部分的代碼結(jié)合起來，本程序也不例外，需要編寫這兩方面的代碼。系統(tǒng)功能模塊圖如圖1.1所示。UDP文件傳輸系統(tǒng)功能描述：（1）客戶端與服務端能夠相互連接； （2）客戶端與服務端能進行文件的發(fā)送和接收； （3）服務端能夠完整地接收并讀取客戶端所發(fā)送的文件； （4）能夠在文件傳輸過程中中斷該

7、傳輸。需求分析表如表1.1所示表1.1 需求分析表需求功能需求描述文件分包處理1、將一個文件分成若干小包以便于文件的傳輸文件發(fā)送1、文件能在客戶端和服務端之間進行傳輸；2、在傳輸過程中能夠顯示文件信息，如文件名、保存路徑、文件大小、傳輸進度等文件接收與讀取1、能夠接收文件；2、能夠讀取文件2 UDP文件傳輸系統(tǒng)基本功能的實現(xiàn)2.1 實現(xiàn)“文件分包處理”功能首先使用WSAStartup()函數(shù)檢查系統(tǒng)協(xié)議棧的安裝情況，然后使用socket()函數(shù)創(chuàng)建套接口1，以確定協(xié)議類型，再調(diào)用bind()函數(shù)將創(chuàng)建的套接口與本地地址綁定，目的是確定本地地址和端口號2。然后再在計算機中選擇一個文件進行讀取工作

8、，通過調(diào)用fread,fwrite,fopen,fclose等函數(shù)實現(xiàn)對文件的打開、讀寫和關(guān)閉，通過輸入文件所在位置來查找文件，若目標文件存在，則繼續(xù)執(zhí)行程序，將所選文件分裝在定義數(shù)組內(nèi)，等待傳輸；若目標文件不存在，則輸出“ERROR”跳出程序執(zhí)行?；赨DP文件傳輸系統(tǒng)文件分包處理UDP文件傳輸客戶端控制協(xié)議圖1.1 系統(tǒng)功能模塊圖2.2 實現(xiàn)“文件傳輸”功能要實現(xiàn)該功能，需要調(diào)用recvfrom函數(shù)和sendto函數(shù)來實現(xiàn)文件的接收功能和發(fā)送功能。文件傳輸結(jié)束后，使用closesocket()函數(shù)關(guān)閉套接口，最后調(diào)用WSACleanup()函數(shù)，結(jié)束Windows Sockets API3

9、。2.3 實現(xiàn)“客戶端接收”功能首先使用socket()來建立一個UDP socket(),第二個參數(shù)為SOCK_DGRAM。然后初始化sockaddr_in結(jié)構(gòu)變量并賦值。接著使用bind()把上面的socket()和定義的IP地址和端口綁定。這里檢查bind()是否執(zhí)行成功，如果有錯誤就退出。這樣可以防止服務程序重復運行的問題。最后進入無限循環(huán)程序，使用recvfrom()進入等待狀態(tài)，直到接收到客戶程序發(fā)送的數(shù)據(jù)，就處理收到的數(shù)據(jù)，并向客戶程序發(fā)送反饋。這里是直接把收到的數(shù)據(jù)發(fā)回給客戶程序。UDP文件傳輸系統(tǒng)主界面圖如圖2.1所示。圖2.1 UDP文件傳輸系統(tǒng)主界面圖3 UDP文件傳輸系

10、統(tǒng)的調(diào)試與運行隨著計算機網(wǎng)絡的不斷發(fā)展，軟件調(diào)試技術(shù)也逐漸成熟，調(diào)試方法也越來越多樣化，針對性更強。大體上來講軟件調(diào)試可分為兩類：靜態(tài)調(diào)試和動態(tài)調(diào)試。靜態(tài)調(diào)試，即先輸出寄存器的內(nèi)容。在測試中出現(xiàn)問題，設法保留現(xiàn)場信息。把所有寄存器和主存中有關(guān)部分的內(nèi)容打印出來，進行分析研究。用這種方法調(diào)試，輸出的是程序的靜止狀態(tài)（程序在某一時刻的狀態(tài)）為取得關(guān)鍵變量的動態(tài)值，在程序中插入打印語句。這是取得動態(tài)信息的簡單方法，并可檢驗在某時間后某個變量是否按預期要求發(fā)生了變化。此方法的缺點是可能輸出大梁需要分析的信息，必須修改源程序才能插入打印語句，這可能改變關(guān)鍵的時序關(guān)系，引入新的錯誤。而動態(tài)調(diào)試則通常利用程

11、序語言提供的調(diào)試功能或?qū)ｉT的調(diào)試工具來分析程序的動態(tài)行為。一般程序語言和工具提供的調(diào)試功能有檢查主存和寄存器；設置斷點，即當執(zhí)行到特定語句或改變特定變量的值時，程序停止執(zhí)行，以便分析程序此時的狀態(tài)。4本程序則主要是對程序的每一個功能逐一測試，針對出現(xiàn)的問題不斷調(diào)試，修改代碼，最后達到滿意的效果。本軟件測試采用動態(tài)測試方法。其中關(guān)鍵的技術(shù)是如何設計有效的測試用例，以便用最小的代價達到測試的目的。軟件需求測試結(jié)論在經(jīng)過對各模塊的測試后，已經(jīng)能夠證實該軟件各方面的能力都可以。只是在支持播放格式上還有待加強。測試分析報告是在測試分析的基礎上，對測試的結(jié)果以及測試的數(shù)據(jù)等加以記錄和分析總結(jié)。它也是測試過

12、程中的一個重要環(huán)節(jié)，同時，它也是對軟件性能的一個總的分析和認可及對不足之處的說明。因此，測試分析報告對于今后對軟件的功能的加強，不足之處的彌補等都起著十分重要的提綱作用。另外，它還有利于今后軟件開發(fā)者閱讀原程序，根據(jù)測試提供的數(shù)據(jù)和結(jié)果，分析原代碼，掌握各函數(shù)的功能和局限性。從而縮短軟件開發(fā)者的再開發(fā)時間和所耗費的精力。從這方面上，我們不難發(fā)現(xiàn)，測試分析報告所指明的對象主要是針對于軟件開發(fā)者5。4 結(jié)論該系統(tǒng)實現(xiàn)了文件在服務端與客戶端之間的傳輸，并對該傳輸過程加以控制，即保證文件的完整傳輸和可在傳輸過程隨時中斷該過程。UDP文件傳輸系統(tǒng)的開發(fā)主要應用了C語言編程技術(shù)和多線程編程技術(shù)。C語言知識

13、的運用使得UDP文件傳輸系統(tǒng)的基本功能很容易地實現(xiàn)了，對代碼的優(yōu)化、縮減是對C語言編程的再一次應用。雖然UDP是一種不可靠的網(wǎng)絡協(xié)議，但是在絕大多數(shù)情況下UDP協(xié)議都是非常有用的，因為UDP具有TCP所望塵莫及的速度優(yōu)勢。雖然TCP協(xié)議中植入了各種安全保障功能，但是在實際執(zhí)行的過程中會占用大量的系統(tǒng)開銷，無疑使速度受到了嚴重的影響。反觀UDP由于排除了信息可靠傳遞機制，將安全和排序功能交給上層應用來完成，極大，極大降低了執(zhí)行時間，使速度得到了保證。Winsock規(guī)范不是一種網(wǎng)絡協(xié)議，而是一套開放的、支持多種協(xié)議的Windows寫的網(wǎng)絡編程接口。Winsock可以訪問很多種網(wǎng)絡協(xié)議，可以把它當做

14、一種協(xié)議的封裝。在使用Winsock進行編程時，需要在指令中調(diào)用API函數(shù)，與Winsock有關(guān)的API，即WSAStartup函數(shù)，初始化Winsock服務，才能調(diào)用Winsock API函數(shù)；WSACleanup函數(shù)，用來終止Winsock的使用；socket函數(shù)、closesocket函數(shù)、send函數(shù)、recv函數(shù)、bind函數(shù)、 listen函數(shù)、accept函數(shù)、connect函數(shù)等。用connect()調(diào)用建立與另一套接口的連接，連接成功后，即可用send()和recv()傳送數(shù)據(jù)。當會話結(jié)束后，調(diào)用closesocket()。帶外數(shù)據(jù)根據(jù)規(guī)定用send()和recv()來接收。

15、如果終端協(xié)議有緩沖區(qū)空間，且數(shù)據(jù)不能在一定時間成功發(fā)送，則認為連接中斷，其后續(xù)的調(diào)用也將以WSAETIMEOUT錯誤返回。SOCK_DGRAM類型套接口允許使用sendto()和recvfrom()從任意端口發(fā)送或接收數(shù)據(jù)報。如果這樣一個套接口用connect()與一個指定端口連接，則可用send()和recv()與該端口進行數(shù)據(jù)報的發(fā)送與接收。UDP文件傳輸系統(tǒng)雖然可以實現(xiàn)文件的傳輸，傳輸過程可現(xiàn)實文件信息，如文件名、保存路徑、文件大小、傳輸進度等，還可以在傳輸過程中隨時取消該進程，傳輸速度非?？欤也僮骱唵?，這些都是UDP傳輸系統(tǒng)的優(yōu)點。但是仍然存在很多不足，在傳送小文件時缺點體現(xiàn)還不明顯，而傳輸大文件時總是或多或少的存在丟包的現(xiàn)象，該問題始終沒有很好的解決，用戶界面方面沒有什么顯著特點，不夠美觀，這些還需要后期開發(fā)時再對UDP文件傳輸系統(tǒng)進行改進和優(yōu)化。參考文獻1