雙協(xié)議實現(xiàn)文件傳輸

1、網(wǎng)絡(luò)程序設(shè)計與實踐大作業(yè)實驗報告題目：TCP/UDP雙協(xié)議實現(xiàn)文件傳輸學號： xxxxxxxxxx 姓名： xxx 指導教師： xxx 學院： xxxxxxxxxxxxxxxxxxx 學校： xxxxxxxxxxxxx 一、 實驗?zāi)康耐ㄟ^學習實踐深入理解TCP/UDP等傳輸協(xié)議，掌握socket網(wǎng)絡(luò)編程，理解它們的工作機制，并在實驗中實現(xiàn)TCP/UDP雙協(xié)議傳輸，通過自己的實現(xiàn)方式保證UDP的可靠傳輸，并使用進程預(yù)分配技術(shù)提高服務(wù)的性能。二、實驗要求1.同時運行基于TCP與UDP的雙協(xié)議2.基于UDP協(xié)議的可靠傳輸3.應(yīng)用進程預(yù)分配技術(shù)4.不上傳，只下載三、實驗平臺與語言Linux Ubunt

2、u9.04，C語言四、實驗設(shè)計思路1.進程預(yù)分配設(shè)計創(chuàng)建一個進程的時間比較長，如果在接收到客戶端請求之后，創(chuàng)建一個子進程來處理，這會影響響應(yīng)客戶機的速度，為解決這個問題，采用一種稱為“預(yù)創(chuàng)建(perfork)”的技術(shù)。服務(wù)器事先創(chuàng)建一定數(shù)目的子進程，對于TCP連接，每個子進程分別調(diào)用函數(shù)accept()從傾聽套接字完成連接隊列中接收已建立的客戶機連接。對于UDP情況，由于要實現(xiàn)可靠傳輸，客戶機要向服務(wù)器發(fā)送的數(shù)據(jù)報確認信息，這就會使其他進程認為這是一個新的連接，所以在這里我采用信號量機制，使得在一段時間內(nèi)，只有一個進程在處理UDP連接，只有這個UDP連接處理完成后，其他進程才可以接收UDP連接

3、并進行處理。也就是說，采用進程預(yù)分配技術(shù)后，可以實現(xiàn)TCP并發(fā)服務(wù)，UDP循環(huán)服務(wù)。使用預(yù)創(chuàng)建技術(shù)的服務(wù)器如圖1。圖1 預(yù)創(chuàng)建子進程方式服務(wù)器預(yù)先創(chuàng)建N個子進程，部分子進程正在處理客戶機請求，部分子進程正在等待客戶機請求。這種服務(wù)器的優(yōu)點是響應(yīng)客戶機的速度比較快，節(jié)省創(chuàng)建子進程的時間。但缺點是服務(wù)器預(yù)先估計所需創(chuàng)建的子進程數(shù)目。如果數(shù)目太少，那么多余的客戶機講等待，不能及時得到服務(wù)，而太多又會浪費系統(tǒng)資源。為了解決上面的問題，服務(wù)器父進程可以動態(tài)的調(diào)整子進程數(shù)目，當空閑子進程數(shù)目小于下限時，父進程創(chuàng)建一些新的子進程；當空閑子進程大于上限時，父進程終止一些子進程。父進程需要兩條消息來管理子進程：

4、子進程接收一個連接和結(jié)束一個連接。當父進程接收的前一種消息時，將檢查空閑子進程數(shù)目是否小于下限；當父進程接收都后一種消息時，將檢查空閑子進程是否大于上限。為了獲得這兩種消息，父進程和每個子進程建立一個管道。當子進程接收到一條連接后，向這個管道中發(fā)送一字節(jié)消息，內(nèi)容為1；當子進程處理完一個連接之后，向這個管道發(fā)送一個字節(jié)消息，內(nèi)容為0.服務(wù)器的示意圖如圖2所示。圖2 動態(tài)更改子進程個數(shù)為了管理子進程，定義一個結(jié)構(gòu)child_queue，記錄活動子進程數(shù)目，空閑子進程數(shù)目和子進程信息隊列。子進程信息隊列記錄了每個子進程的信息：子進程的進程號，與父進程通信的管道和子進程的狀態(tài)。子進程狀態(tài)可能是等待客

5、戶機請求（CS_WAITING）或處理客戶機請求（CS_PROCESSING）。struct child_queue /結(jié)構(gòu):用于管理子進程 int chld_no; /活動子進程數(shù)目 int chld_avail; /空閑子進程數(shù)目 struct child_info /子進程信息int pid; /子進程進程號int pipefd; /與子進程通信的管道int state; /子進程狀態(tài) ciCHILD_NUM_MAX; /子進程信息數(shù)組;服務(wù)器一直循環(huán)動態(tài)管理子進程數(shù)目，知道有SIGINT信號出現(xiàn)（CTRL+C），才Kill所以子進程，退出循環(huán)，結(jié)束。進程預(yù)分配的流程圖如圖3所示。圖3

6、進程預(yù)分配流程圖2.子進程處理連接及雙協(xié)議實現(xiàn) 當一個子進程被創(chuàng)建后，它循環(huán)等待客戶機連接請求，當客戶機連接請求到達后，它判斷是TCP連接，還是UDP連接。如果是TCP連接，子進程調(diào)用tcpfile()函數(shù)處理連接請求，在tcpfile()處理請求過程中，調(diào)用accept()函數(shù)從傾聽套接字完成連接隊列中接收已建立的連接，如果接收成功則通過管道通知父進程開始處理連接，父進程把它的狀態(tài)置為CS_PROCESSING(處理客戶機請求)，然后判斷空閑子進程數(shù)目是否小于下限，如果小于，則創(chuàng)建一定數(shù)目新的子進程。當連接處理完成后，子進程通過管道通知父進程連接處理完成，父進程把它的狀態(tài)置為CS_WAITI

7、NG，然后判斷空閑子進程數(shù)目是否超過上限，如果超過，Kill一定數(shù)目的空閑子進程。而處理此次連接的子進程處理完成后繼續(xù)等待新的連接。如果是UDP連接子進程先判斷是否有其他進程正在調(diào)用udpfile()函數(shù)處理UDP連接，如果有，則說明這個連接有可能是客戶端發(fā)送給服務(wù)器的數(shù)據(jù)報確認信息，那么子進程繼續(xù)等待新的連接。如果沒有其他子進程正在調(diào)用udpfile()函數(shù)處理udp連接，則對信號量執(zhí)行P操作，然后調(diào)用udpfile處理本次UDP連接，處理完成后對信號量執(zhí)行V操作，以便其他子進程調(diào)用udpfile()函數(shù)處理新的UDP連接。在調(diào)用udpfile()處理UDP連接時，同樣需要通過管道和父進程通

8、信，以便父進程動態(tài)管理子進程數(shù)目。子進程處理連接流程圖如圖4所示。圖4 子進程處理連接客戶端服務(wù)器1.請求連接2.響應(yīng)連接3.請求文件4.響應(yīng)請求5.請求發(fā)送6.傳輸數(shù)據(jù)圖5 基于TCP協(xié)議的通信方式3.基于TCP協(xié)議文件傳輸?shù)脑O(shè)計TCP，UDP屬于傳輸層協(xié)議，無法直接應(yīng)用于傳輸文件。所以無論基于TCP還是基于UDP都需要單獨開發(fā)各自獨立的應(yīng)用層協(xié)議。由于TCP協(xié)議提供可靠地傳輸，所以我們就不用考慮可靠性。圖5是客戶端和服務(wù)器端基因TCP協(xié)議的通信方式。圖6 基于TCP的服務(wù)器端流程圖 客戶端首先請求連接，當收到連接確認后，發(fā)送要下載的文件名，如果文件在服務(wù)器端存在，服務(wù)器給客戶端發(fā)文件存在確

9、認信息，如果文件不存在，服務(wù)器給客戶端發(fā)文件不存在信息。如果文件不存在，客戶端提示文件不存在，重新輸入文件名并發(fā)送。如果文件存在，服務(wù)器發(fā)送文件數(shù)據(jù)，客戶端接收服務(wù)器發(fā)送的文件數(shù)據(jù)，一直循環(huán)直到文件傳輸完畢。然后客戶端關(guān)閉套接字，端口連接，而服務(wù)器端子進程，處理完本次連接后繼續(xù)等待新的連接到來。圖6是基于TCP的服務(wù)器端流程圖，圖7是客戶端流程圖。由于服務(wù)器采用進程預(yù)分配，TCP套接字和傾聽套接字都是在父進程中創(chuàng)建的，在圖6服務(wù)器端流程圖中沒有體現(xiàn)出來。圖7 基于TCP的客戶端流程圖4.基于UDP協(xié)議文件傳輸?shù)脑O(shè)計由于UDP協(xié)議不提供可靠傳輸，所以在這里我們需實現(xiàn)可靠傳輸機制。在這里應(yīng)用的是停

10、等超時機制，圖8顯示了基于UDP協(xié)議的客戶端和服務(wù)器端的通信方式?？煽總鬏敊C制可以描述如下：在文件傳輸過程中，服務(wù)器端先給文件數(shù)據(jù)報進行0或1編號（規(guī)定編號從0開始），然后發(fā)送數(shù)據(jù)報，計時等待接收客戶端數(shù)據(jù)報編號ACK，如果服務(wù)器端未在規(guī)定時間內(nèi)收到客戶端編號ACK，則重新發(fā)送本次數(shù)據(jù)報，如果服務(wù)器端在規(guī)定時間內(nèi)接到客戶端的編號ACK，則判斷編號ACK和本次發(fā)送的是否相同，如果相同，則對下一個數(shù)據(jù)報進行1或0編號并發(fā)送；如果客戶端的編號ACK與本次發(fā)送的不同，則說明客戶端沒有收到本次數(shù)據(jù)報，重新發(fā)送，計時等待客戶端數(shù)據(jù)報編號ACK。如果重新發(fā)送次數(shù)超過10次都沒有收到客戶端編號ACK，則認為客

11、戶端斷開了連接，服務(wù)器子進程返回繼續(xù)等待新的連接。正常情況到文件發(fā)送完畢，然后服務(wù)器子進程給客戶端發(fā)送一個文件發(fā)送完畢信息。不等待客戶確認，然后返回繼續(xù)等待新的連接?；赨DP協(xié)議服務(wù)器端流程圖如圖9所示?？蛻舳朔?wù)器0.請求連接0回應(yīng)連接1.請求文件1.回應(yīng)請求2.請求傳輸2.傳輸數(shù)據(jù)。100.請求傳輸100.文件結(jié)束101.收到文件結(jié)束101.請求斷開102.確認斷開圖8 基于UDP的客戶端和服務(wù)器端通信方式而基于UDP的客戶端，一開始發(fā)送請求的文件名字并得到存在確認后，就開始等待服務(wù)器端的數(shù)據(jù)報（由于規(guī)定數(shù)據(jù)報編號從0開始，第一個接收到的數(shù)據(jù)報編號應(yīng)該為0，然后以后依次為1.0.1.0）

12、，接收到一個數(shù)據(jù)報后，判斷是否是希望得到的編號的數(shù)據(jù)報，如果是，則給服務(wù)器端發(fā)送本次得到的數(shù)據(jù)報編號ACK，如果不是就給服務(wù)器端發(fā)送上次的數(shù)據(jù)報編號ACK。圖10是基于UDP協(xié)議的客戶端流程圖。圖9 基于UDP協(xié)議的服務(wù)器端流程圖圖10 基于UDP協(xié)議的客戶端流程圖五、實驗結(jié)果與分析為了方便觀察，每次TCP或UDP連接，在服務(wù)器端都顯示連接類型，IP和端口，以及下載的文件。1. 基于TCP協(xié)議的文件傳輸圖11 服務(wù)器運行圖12 客戶端連接圖13 服務(wù)器端顯示TCP連接圖14 客戶端輸入文件名data并下載圖15 服務(wù)器端TCP連接顯示下載文件data2. 基于UDP協(xié)議的文件傳輸圖16 UDP客戶端運行并輸入文件名圖17 UDP客戶端連接并下載文件圖18 服務(wù)器端顯示UDP連接及下載的文件 從圖18可以看出服務(wù)器實現(xiàn)了TCP和UDP雙協(xié)議。當有TCP連接時調(diào)用tcpfile()函數(shù)進行處理，當有UDP連接時調(diào)用udpfile()函數(shù)進行處理。3. 進程預(yù)分配圖19 有5個TCP客戶端同時連接圖20 服務(wù)器端預(yù)分配的5個子進程分別對每個連接處理4. UDP超時重傳圖21 UDP客戶端下載文件圖22 服務(wù)器超時重傳六、實驗總結(jié)由