課程設計報告滑動窗口協(xié)議仿真

1、滁州學院課程設計報告課程名稱:計算機網(wǎng)絡設計題目:滑動窗口協(xié)議仿貞別:計算機與信息工程學院業(yè):計算機科學與技術別:第五組趙國柱起止日期：2011年n月24 口2011年12月7 n 指導教師:計算機與信息工程學院二O一年制課程設計所需環(huán)開發(fā)環(huán)境:VC+運彳亍環(huán)境:Windows操作系統(tǒng)境課程設計任務要求1. 程用按照滑動窗口協(xié)議實現(xiàn)端對端的數(shù)據(jù)傳送。包 括協(xié)議的各種策略，如包丟失、停等應答、超時等都應有所仿真實現(xiàn)2. 顯示數(shù)據(jù)傳送過程中的各項具體數(shù)據(jù)。雙方幀的個 數(shù)變化，幀字號，發(fā)送和接受速度，暫?；蛑貍魈崾镜日n程設計工作進度計劃序號起止期工作內(nèi)容分工情況111 月 24 號F月 27號了解工

2、作要求，明確分工內(nèi)容，網(wǎng)上查閱相關資料所有組員共同參與211 月 28 號F月30號sender隊列模塊的編寫由閆婷完成312月1號12 月 4號sender主函數(shù)的編寫由趙育坤、張飛完成411 月 28 號F月30號receiver隊列模塊的編寫由張俠完成512月1號12 月 4 號receiver主函數(shù)的編寫由余靜、于東鋒完成612月5號12 月 7號最后匯總，調(diào)試由趙育坤、于東鋒完成指導教師簽字：年月n教研室市核意見：教研室主任簽字：年月n課程設計任務書一.引言 二-基本原理窗口機制Ibit滑動窗口協(xié)議 后退N協(xié)議 選擇重傳協(xié)議 流量控制三.需求分析課程設計題目 開發(fā)環(huán)境運行環(huán)境課程設計

3、任務及要求界面要求網(wǎng)絡接口要求0.詳細設計結構體的定義發(fā)送方的主要函數(shù)接受方的主要函數(shù)五.源代碼發(fā)送方的主要代碼接收方的主要代碼調(diào)試與操作說明致謝參考文獻課程設計的主要內(nèi)容L引言早期的網(wǎng)絡通信中，通信雙方不會考慮網(wǎng)絡的擁擠情況直接發(fā)送 數(shù)據(jù)。由于大家不知道網(wǎng)絡擁塞狀況，一起發(fā)送數(shù)據(jù)，導致中間結點 阻塞掉包，誰也發(fā)不了數(shù)據(jù)。在數(shù)據(jù)傳輸過程中，我們總是希望數(shù)據(jù) 傳輸?shù)母煲恍?，但如果發(fā)送方把數(shù)據(jù)發(fā)送的過快，接收方就可能來不 及接收，這就造成數(shù)據(jù)的丟失。因此就有了滑動窗口機制來解決這些 問題。早期我們使用的是Ibit滑動窗口協(xié)議，一次只發(fā)送一個幀,等收到ack確認才發(fā)下一個幀，這樣對信道的利用率太低

4、了。因此提 出了一種采用累積確認的連續(xù)ARQ協(xié)議，接收方不必對收到的幀逐個發(fā)送 ack確認，而是收到兒個幀后，對按序到達的最后一個幀發(fā)送ack確認。同Ibit滑動窗口協(xié)議相比，大大減少了 ack數(shù)量，并消除了延遲ack對 傳輸效率的影響。但是，這會產(chǎn)生一個新的問題，如果發(fā)送方發(fā)送了 5個 幀，而中間的第3個幀丟失了。這時接收方只能對前2個幀發(fā)出確認。發(fā) 送方無法知道后面三個幀的下落，只好把后面的3個幀再重傳一次，這就 是回退N協(xié)議。為了解決這個問題，乂提出了選擇重傳協(xié)議。當接收方 發(fā)現(xiàn)某幀出錯后，繼續(xù)接受后面送來的正確的幀，只是不交付它們, 存放在自己的緩沖區(qū)中，并且要求發(fā)送方重傳出錯的那一幀

5、。一S收 到重傳來的幀后，就可以將存于緩沖區(qū)中的其余幀一并按正確的順序 遞交給主機。2. 基本原理窗口機制滑動窗口協(xié)議的基本原理就是在任意時刻，發(fā)送方都維持了一個連 續(xù)的允許發(fā)送的幀的仔號，稱為發(fā)送窗口：同時，接收方也維持了一個 連續(xù)的允許接收的幀的序號，稱為接收窗口。發(fā)送窗口和接收窗口的序 號的上下界不一定要一樣，至大小也可以不同。不同的滑動窗口協(xié)議 窗口大小一般不同。發(fā)送方窗口內(nèi)的斥號代表了那些己經(jīng)被發(fā)送，但是 還沒有被確認的幀，或者是那些可以被發(fā)送的幀。接受方為其窗口內(nèi)的每一個/號保留了一個緩沖區(qū)。與每個緩沖區(qū)相關聯(lián)的還有一位，用來指 明該緩沖區(qū)是滿的還是空的。若從滑動窗口的觀點來統(tǒng)一看

6、待1比特滑動窗口.后退n及選擇重傳三種協(xié)議，它們的差別僅在于各自窗口尺寸的大小不同而已。1 比特滑動窗口協(xié)議：發(fā)送窗口=1,接收窗口 = 1;后退N協(xié)議：發(fā)送窗 口 1,接收窗口 =1:選擇重傳協(xié)議：發(fā)送窗口 1,接收窗口 1。Ibit滑動窗口協(xié)議當發(fā)送窗口和接收窗口的大小固定為1時，滑動窗口協(xié)議退化為停 等協(xié)議(stop and wait ) o該協(xié)議規(guī)定發(fā)送方每發(fā)送一幀后就要停下 來，等待接收方已正確接收的確認(acknowledgement)返回后才能繼續(xù) 發(fā)送下一幀。由于接收方需要判斷接收到的幀是新發(fā)的幀還是重新發(fā)送 的幀，因此發(fā)送方要為每一個幀加一個序號。由于停等協(xié)議規(guī)定只有一 幀完

7、全發(fā)送成功后才能發(fā)送新的幀，因而只用一比特來編號就夠了。其 發(fā)送方和接收方運行的流程圖如圖所示。后退N協(xié)議由于停等協(xié)議要為每一個幀進行確認后才繼續(xù)發(fā)送下一幀，大大 降低了信道利用率，因此乂提出了后退n協(xié)議。后退n協(xié)議中，發(fā)送 方在發(fā)完一個數(shù)據(jù)幀后，不停下來等待應答幀，而是連續(xù)發(fā)送若干個 數(shù)據(jù)幀，即使在連續(xù)發(fā)送過程中收到了接收方發(fā)來的應答幀，也可以 繼續(xù)發(fā)送。且發(fā)送方在每發(fā)送完一個數(shù)據(jù)幀時都要設置超時定時器。只要在所設置的超時時間內(nèi)仍收到確認幀，就要重發(fā)相應的數(shù)據(jù)幀。如：當發(fā)送方發(fā)送了N個幀后，若發(fā)現(xiàn)該N幀的前一個幀在計時器超 時后仍未返回其確認信息，則該幀被判為出錯或丟失，此時發(fā)送方就 不得不

8、重新發(fā)送出錯幀及其后的N幀。從這里不難看出，后退n協(xié)議一方面因連續(xù)發(fā)送數(shù)據(jù)幀而提高了 效率，但另一方面，在重傳時又必須把原來己正確傳送過的數(shù)據(jù)幀進 行重傳(僅因這些數(shù)據(jù)幀之前有一個數(shù)據(jù)幀出了錯)，這種做法又使 傳送效率降低。由此可見，若傳輸信道的傳輸質量很差因而誤碼率較 大時，連續(xù)測協(xié)議不一定優(yōu)于停止等待協(xié)議。此協(xié)議中的發(fā)送窗口的 大小為4接收窗口仍是1。選擇重傳協(xié)議在后退n協(xié)議中，接收方若發(fā)現(xiàn)錯誤幀就不再接收后續(xù)的幀，即使 是正確到達的幀，這顯然是一種浪費。另一種效率更高的策略是當接收 方發(fā)現(xiàn)某幀出錯后，其后繼續(xù)送來的正確的幀雖然不能立即遞交給接收 方的高層，但接收方仍可收下來，存放在一個緩

9、沖區(qū)中，同時要求發(fā)送 方重新傳送出錯的那一幀。一口收到重新傳來的幀后，就可以原已存于 緩沖區(qū)中的其余幀一并按正確的順用遞交高層。這種方法稱為選擇重發(fā) (SELECTICE REPEAT),其工作過程如圖所示。顯然，選擇重發(fā)減少了浪 費，但要求接收方有足夠大的緩沖區(qū)空間。流量控制TCP的特點之一是提供體積可變的滑動窗口機制，支持端到端的 流量控制。TCP的窗口以字節(jié)為單位進行調(diào)整，以適應接收方的處理 能力。處理過程如下:（1）TCP連接階段，雙方協(xié)商窗口尺寸，同時接收方預留數(shù)據(jù)緩存 區(qū):（2）發(fā)送方根據(jù)協(xié)商的結果，發(fā)送符合窗口尺寸的數(shù)據(jù)字節(jié)流，并等 待對方的確認;（3）發(fā)送方根據(jù)確認信息，改變窗

10、口的尺寸，增加或者減少發(fā)送未得 到確認的字節(jié)流中的字節(jié)數(shù)。調(diào)整過程包括：如果出現(xiàn)發(fā)送擁塞，發(fā) 送窗口縮小為原來的一半，同時將超時重傳的時間間隔擴大一倍。（4）滑動窗口機制為端到端設備間的數(shù)據(jù)傳輸提供了可靠的流量控制 機制。然而，它只能在源端設備和目的端設備起作用，當網(wǎng)絡中間設 備（例如路由器等）發(fā)生擁塞時，滑動窗口機制將不起作用。3. 需求分析課程設計題目：滑動窗口協(xié)議仿真開發(fā)環(huán)境J Visual C+運行環(huán)境：Windows操作系統(tǒng)課程設計任務及要求:（1）程序按照滑動窗口協(xié)議實現(xiàn)端對端的數(shù)據(jù)傳送。包括協(xié)議的種策 略，如包丟失.停等應答、超時等都應有所仿真實現(xiàn)。(2)顯示數(shù)據(jù)傳送過程中的各項

11、具體數(shù)據(jù)。雙方幀的個數(shù)變化，幀序 號，發(fā)送和接受速度，暫?；蛑貍魈崾镜取＝缑嬉?此次課程設計要求的所有功能應可視，我們組主要是用VC+編寫 的，運行在DOS環(huán)境下，觀察發(fā)送方(sender)發(fā)送數(shù)據(jù)包到接收方receive)時。界面應顯示出雙方幀個數(shù)的變化，幀序號，發(fā)送和接受 速度，暫停或重傳提示等，界面中必須動態(tài)顯示數(shù)據(jù)幀的發(fā)送和接受情 況，包括在相應的窗口詳細顯示相應的ACK和其他收發(fā)數(shù)據(jù)幀后發(fā)出的消 息，以表明模擬協(xié)議的正確運作過程。在各種情況下，接受方和發(fā)送方 窗口應實時顯示幀的發(fā)送和接受情況，包括序號，時間戳，內(nèi)容等。以 及窗口的填充和清空情況。網(wǎng)絡接口要求: 兩臺機器或是一臺機器

12、中兩個獨立的線程模擬發(fā)送方與接受方，接收數(shù) 據(jù)的端口初始應為監(jiān)聽狀態(tài)。發(fā)送方向接受方發(fā)起連接，成功后開始發(fā) 送數(shù)據(jù)。4. 概要設計結構體定義如下: typedef enum data = 1, ack, nak, tout frame_kind： 代碼發(fā)送方的主要代碼: void InitLine(LinkQueue *q)q-front = q-rear = NULL： int QueueErapty(LinkQueue *q)return q-front = NULL & q-rear = NULL： frame QueueFront(LinkQueue *q)if (QueueEmpty

13、(q)printf (隊列為空！ n);Sleep(SLEEPMS);exit (0);return q-front-head_data;int QueueLen(LinkQueue *q)if (QueueEmpty(q)return 0：int num = 0;Framenode *p = q-front;while(p != NULL)nura+： p = p-next:return num： void GetFrameFromHost(LinkQueue *q)if(QueueLen(q) = MAXPOOL)return;Framenode *p=(Framenode *)mallo

14、c(sizeof(Framenode);srand(unsigned)time(NULL);p- = rand() % MAX_LENGTH： . n)Begin:WORD wVersionRequested：WSADATA wsaData;按 q 退出,其他鍵繼續(xù)）；int kbc = getchO ;if (kbc = q I I kbcbreak;printf （按任意鍵退出！ n）;while (Ikbhit 0) ;Sleep (SLEEPMS);printf (謝謝使用！ n);WSACleanup ();closesocket (socketCllent);Sleep (SLEE

15、PMS):DWORD WINAPI ReceiveFun(LPVOID pArg)EnterCriticalSection(&gCS);elsecurw = DeLine (&QueueQ, &packetreceive, curw):試與操作說明用戶打開接收方程用時會白動等待發(fā)送方，打開發(fā)送方程斥時會自動嘗試連 接接收方程斥。當發(fā)送方程序和接收方程序都打開時，發(fā)送程字將連接接收 方程序，連接成功時會有提示信息。在發(fā)送方按任意鍵開始模擬，發(fā)送與接受是自動進行，出現(xiàn)各種情況（幀丟失、幀出錯、ack丟失等）的概率都是20虬 程序執(zhí)行20秒后會提示是否繼續(xù)執(zhí)行。如圖:b 2是正常情況：發(fā)送方發(fā)送數(shù)據(jù)幀-接受方收到數(shù)據(jù)幀，經(jīng)檢驗該數(shù)據(jù)幀正確，發(fā)送確認幀-發(fā)送方收到確認幀，刪除己收到確認的數(shù)據(jù)幀。3,4是數(shù)據(jù)幀丟失：發(fā)送方發(fā)送數(shù)據(jù)幀-接受方未收到數(shù)據(jù)幀，沒有任何動作- 發(fā)送方超時重傳該數(shù)據(jù)幀。5,6是數(shù)據(jù)幀出錯：發(fā)送方發(fā)送數(shù)據(jù)幀-接收方收到數(shù)據(jù)幀，經(jīng)檢驗該數(shù)據(jù)幀出錯，發(fā)送否認幀-接受方收到否認幀，重傳該數(shù)據(jù)幀。7,8是ack丟失：發(fā)送方發(fā)送數(shù)據(jù)幀-接受方收到數(shù)據(jù)幀，經(jīng)檢驗該數(shù)據(jù)幀正確，發(fā)送確認幀-發(fā)送方未收到確認幀，超時重傳該數(shù)據(jù)幀。7.致謝在設計研究和設計報告撰寫過程中，感謝我的同學和老師給與的關心和幫助，從中我學會了很多，不但是專業(yè)課程的知識