gobackn協(xié)議實驗報告(共20頁)

1、一，描述本次實驗的任務、內容和實驗環(huán)境。1，實驗內容和任務：利用所學數(shù)據(jù)鏈路層原理，自己設計一個滑動窗口協(xié)議，在仿真環(huán)境下編程實現(xiàn)有噪音信道環(huán)境下。兩站點之間無差錯雙工通信。信道模型為8000bps 全雙工衛(wèi)星信道，信道傳播時延270毫秒，信道誤碼率為10-5，信道提供字節(jié)流傳輸服務，網(wǎng)絡層分組長度在240256字節(jié)范圍。深刻理解數(shù)據(jù)鏈路層的字節(jié)填充方式的成幀技術，誤碼檢測的CRC 校驗技術，以及滑動窗口的工作機理。對參數(shù)進行設計，充分理解滑動窗口協(xié)議的工作原理并利用所學的理論知識，經(jīng)過認真的推算，計算出最優(yōu)取值，并通過程序的運行進行驗證。2，實驗設備環(huán)境：WindowsXP環(huán)境PC機，Mic

2、rosoft Visual C+ 6.0 集成化開發(fā)環(huán)境。二， 協(xié)議設計：(1) 設計該協(xié)議的目的，基本原理該實驗協(xié)議包括物理層，數(shù)據(jù)鏈路層和網(wǎng)絡層。本實驗主要設計數(shù)據(jù)鏈路層協(xié)議，實現(xiàn)有噪聲環(huán)境下高信道利用率傳輸，采用了回退n幀技術的協(xié)議。接受方窗口大小為1，發(fā)送方窗口大小為N。通過捎帶確認（piggybacking）來完成可靠的數(shù)據(jù)通信；由于出現(xiàn)信道誤碼而導致收幀出錯時，接受方會丟棄所有的后續(xù)幀，待定時器超時后發(fā)送方重發(fā)。首先從網(wǎng)絡層接受要發(fā)送的數(shù)據(jù)包，將之分拆成數(shù)據(jù)幀；然后按成幀方案完成分幀，加校驗碼，加ack等操作；再進行適當?shù)牧髁颗袛嗪蛽砣刂?；最后啟動定時器將之傳遞給物理層。數(shù)據(jù)幀經(jīng)

3、信道傳送給接受方，接受方數(shù)據(jù)鏈路層執(zhí)行與成幀相逆的操作；處理ack信息，終止定時器（或啟動ack定時器，ack成幀傳送）；判斷是否為預期數(shù)據(jù)，數(shù)據(jù)是否出錯，提交給網(wǎng)絡層。(2) 成幀方案，幀邊界和轉義字符的定義及轉義方法使用的成幀方案：含字節(jié)填充的分界符法，即讓每一幀都用一些特殊的字節(jié)（FLAG）作為開始和結束。當有效載荷域中含有標志字節(jié)或轉義字節(jié)時，在每個在有效載荷域中出現(xiàn)的標志字節(jié)或轉義字節(jié)前均要加一個轉義字節(jié)（ESC）。接受端的數(shù)據(jù)鏈路層在將數(shù)據(jù)送給網(wǎng)絡之前刪除掉轉義字節(jié)。一個數(shù)據(jù)幀如圖所示：起始標志字節(jié)本幀序號捎帶確認序號有效數(shù)據(jù)校驗碼結束標志字節(jié)其中有效數(shù)據(jù)和校驗碼可能含有轉義字符。

4、 (3) 幀中各個字段的定義和編碼，計算CRC校驗和的多項式定義幀的定義編碼：幀中的第一比特為開頭FLAG，第二比特是幀的類型，共定義了data,ack,nak frame_kind三種類型，用枚舉常量表述，第三比特是順序編碼，用于確定到達幀的順序，第四比特是ACK捎帶確認訊息，記錄了當前已收到幀的確認情況，這是數(shù)據(jù)幀的頭部。若為數(shù)據(jù)幀，從第五比特開始為網(wǎng)路層的數(shù)據(jù)，到網(wǎng)路層包裹信息結束后，接上4比特的CRC校驗訊息，后有一結束字符FLAG表明該幀結束。CRC校驗數(shù)：CRC校驗數(shù)據(jù)由函數(shù)crc32()產(chǎn)生，函數(shù)crc32()返回一個32位整數(shù)為數(shù)據(jù)生成CRC-32校驗和，并且把這 32比特校驗

5、和附在數(shù)據(jù)字節(jié)之后。多項式定義：采用的CRC校驗方案為CRC-32，生成多項式為：x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x1+1校驗和附加在數(shù)據(jù)幀尾部，接受方用帶校驗和的數(shù)據(jù)來邏輯除以生成多項式，余數(shù)為零則數(shù)據(jù)無誤碼，反之有誤碼等待發(fā)送方重傳。(4) 協(xié)議工作時兩個站點之間信息交換的過程控制，尤其是發(fā)生誤碼條件下的控制方案協(xié)議工作時，兩個站點通過互發(fā)數(shù)據(jù)包交換數(shù)據(jù)，而控制訊息則稍帶在數(shù)據(jù)訊息中傳遞，當遇到超時情況時，則主動發(fā)送空數(shù)據(jù)包以提供訊息。當出現(xiàn)幀丟失時，如收到幀的序號有跳躍，或者出現(xiàn)CRC校驗出錯丟棄了某幀，會主動發(fā)送NAK否定幀

6、，提示重傳，接收方丟棄所有的后續(xù)幀。若長期未產(chǎn)生放送消息，則出現(xiàn)ACK超時事件，主動發(fā)送ACK幀提示確認，對方收到確認后，滑動窗口繼續(xù)發(fā)送，若一直未收到確認訊息，則出現(xiàn)數(shù)據(jù)幀超時事件，發(fā)送方會自動重發(fā)未確認幀。11.3 軟件設計給出程序的數(shù)據(jù)結構，模塊之間的調用關系和功能，程序流程。(1) 數(shù)據(jù)結構：數(shù)據(jù)結構是整個程序的要點之一，程序維護者充分了解數(shù)據(jù)結構就可以對主要算法和處理流程有個基本的理解。描述程序中自定義結構體中各成員的用途，定義的全局變量和主函數(shù)中的變量的變量名和變量所起的作用。采用字符數(shù)組結構來存放數(shù)據(jù)幀：typedef unsigned char seq_nr;typedef u

7、nsigned char packetPKT_LEN;typedef unsigned char frame_kind;typedef struct FRAME frame_kind kind; /* FRAME_DATA */ seq_nr ack; seq_nr seq; packet info; unsigned int padding; frame; 其中：frame kind 是幀的類型。Ack 捎帶確認數(shù)據(jù)幀是否正確傳到Seq 是數(shù)據(jù)幀傳輸?shù)男蛱杋nfo是幀傳輸?shù)膬热軵adding是幀經(jīng)過CRC校驗之后所添加的內容定義的全局變量：static int phl_ready 表示物理層

8、的狀態(tài)int out_buffer_lenMAX_SEQ + 1 從網(wǎng)絡層得到的數(shù)據(jù)包的長度主函數(shù)中的變量的變量名和變量：int event 接收方等待的發(fā)生事件int arg 物理層到達的字數(shù)packet bufferMAX_SEQ+1; 發(fā)送方的數(shù)據(jù)包緩存區(qū)seq_nr nbuffered 當前幀號seq_nr next_frame_to_send 下一個要發(fā)送的幀的序號seq_nr ack_expected 期望收到的確認seq_nr frame_expected; 期望接收到對方的幀的編號frame r; 變量幀(2) 模塊結構：給出程序中所設計的子程序所完成的功能，子程序每個參數(shù)的意

9、義。給出子程序之間的程序調用關系圖。函數(shù)between(seq_nr a,seq_nr b,seq_nr c)用于判斷收到的ACK序號是否在發(fā)送窗口內。a為下限，b為ack序號，c為上限。函數(shù)send_to_physical(unsigned char *out_buf, int slen)用字符填充方式將幀發(fā)送到物理層函數(shù)recv_from_physical(unsigned char *in_buf, int arg)用于從物理層接收一個字節(jié)并做處理函數(shù)send_data_frame(frame_kind fk, seq_nr frame_nr, seq_nr frame_expected

10、, packet buffer) 用于發(fā)送從網(wǎng)絡層得到的數(shù)據(jù)函數(shù)調用圖為：主函數(shù)mainsend_data_framrecv_from_physicalsend_to_physicalbetween(3) 算法流程：畫出流程圖，描述算法的主要流程。11.4 實驗結果分析（1）描述所實現(xiàn)的協(xié)議軟件是否實現(xiàn)了有誤碼信道環(huán)境中無差錯傳輸功能。能實現(xiàn)協(xié)議軟件是否實現(xiàn)了有誤碼信道環(huán)境中無差錯傳輸功能，采用了CRC校驗和重傳技術是錯誤得以被發(fā)現(xiàn)和糾正。(2) 程序的健壯性如何，能否可靠地長時間運行。程序健壯性較好，在高負荷和高誤碼率等條件下均能工作。在較低誤碼率的信道條件下，該程序運行平穩(wěn)，沒有出現(xiàn)任何差

11、錯，健壯性良好，在高誤碼率的信道條件下，程序運行有時會出現(xiàn)中斷，但大多數(shù)時候運行時間較長，故本程序健壯性良好。(3) 協(xié)議參數(shù)的選?。夯瑒哟翱诘拇笮?，重傳定時器的時限， ACK 搭載定時器的時限，這些參數(shù)是怎樣確定的？根據(jù)信道特性數(shù)據(jù)，分組層分組的大小，以及你的滑動窗口機制，給出定量分析，詳細列舉出選擇這些參數(shù)值的具體原因。本次實驗中物理層提供了一種字節(jié)流傳輸服務，為了成幀，使用了字節(jié)填充技術。分組長度為240256字節(jié)。 滑動窗口的大小：該參數(shù)的選擇直接涉及到信道利用率和數(shù)據(jù)擁塞的問題；若太小，會導致信道利用率很低，信道中長時間沒有數(shù)據(jù)傳送；若太大，數(shù)據(jù)發(fā)送過快，會造成接受方數(shù)據(jù)鏈路層來不及

12、處理，數(shù)據(jù)物理層及信道發(fā)生擁塞現(xiàn)象導致數(shù)據(jù)丟失，出錯率增大。在go_back_n協(xié)議中（假設接受方一直有數(shù)據(jù)發(fā)送，即無ack定時器超時現(xiàn)象），滑動窗口的大小M,信道傳輸時延a,發(fā)送速率c，幀大小f在滿足如下關系時信道利用率（M*(f/c)/2a+2(f/c)）接近100%:M=2a+2*(f/c)/（f/c）;由于實際數(shù)據(jù)傳送很可能在某段時間類接受方無數(shù)據(jù)反送，涉及ack幀單獨傳送問題，故一般信道利用率不可能達到100%，但M的選擇至少要滿足公式。至于防止M過大的問題，可通過實際測試的結果分析來得到合適的M值。最終，我們選擇M值為31，效果較好。重傳定時器的時限：該參數(shù)的選擇涉及到重傳的相應時

13、間，若改時間選擇過大，則會導致重傳等待的時間過久，若時間選擇過小，則將導致較為頻繁的重傳，這兩種情況均將導致信道利用率的下降，經(jīng)過實際檢測，當wait_time設為1700ms時，效果較好。Ack搭載定時器的時限：若該值選擇較小，則將導致頻繁重傳ack幀，雖然我們在程序中將ack幀的長度設定為8（最小長度），但頻繁的重傳仍將降低信道利用率；若將該值設置過大，則發(fā)送方將長時間得不到ack確認信號，嚴重時將導致重傳，降低利用率。經(jīng)過實際測試，ack_time選擇為240-300ms內，效果較好。(5) 理論分析：根據(jù)所設計的滑動窗口工作機制(Go-Back-N)，推導出在無差錯信道環(huán)境下分組層能獲

14、得的最大信道利用率；推導出在有誤碼條件下重傳操作及時發(fā)生等理想情況下分組層能獲得的最大信道利用率。給出理論推導過程。理論推導的目的是得到信道利用率的極限數(shù)據(jù)。為了簡化有誤碼條件下的最大利用率推導過程，可以對問題模型進行簡化，比如：假定超時重傳的數(shù)據(jù)幀的回饋ACK 幀可以100%正確傳輸，但是簡化問題分析的這些假設必須不會對整個結論產(chǎn)生較大的誤差。由于需要攜帶幀訊息，因此最大的信息利用率為約為96.2%，由于信道的最大比特率為8000bps，可得出每傳輸一個字節(jié)耗時1ms，每幀的附加訊息固定為10，耗時10ms，若出現(xiàn)轉義字符，則可能增加時間，在ESC/FLAG模式中傳輸?shù)钠骄?50個字符需要兩

15、倍的傳輸空間即極限值500，此時的信道利用率的極限值是49%，若平均每個錯幀重傳10次，利用率將下降為40%。 (6) 實驗結果分析：你的程序運行實際達到了什么樣的效率，比對理論推導給出的結論，有沒有差距？給出原因。有沒有改進的辦法？如果沒有時間把這些方法付諸編程實施，介紹你的方案。實驗所得的結果是無差錯條件下分組層能獲得的最大信道利用率對于A是50%，對于B是100%。(7) 存在的問題：在“表3 性能測試記錄表”中給出了7 種測試方案，在測試中你的程序有沒有失敗，或者，雖未失敗，但表現(xiàn)出來的性能仍有差距，你的程序中還存在哪些問題?在誤碼率不同的情況下所執(zhí)行程序的結果截圖如下：當參數(shù)為u的運

16、行結果：無參數(shù)時運行結果為：參數(shù)為fu的運行結果：參數(shù)為f的的運行結果如下：當參數(shù)為fs時的運行結果如下：該圖參數(shù)為afs：該圖參數(shù)為bfs：當參數(shù)為fle的運行結果：該圖的參數(shù)為afle該圖的參數(shù)為bfle當參數(shù)為fl時的運行效果如下：當參數(shù)為f ber 1e-7時的運行效果：當參數(shù)為f ber 5e-5時程序運行效果如下：當參數(shù)為f ber 5e-4時候的運行效果如下：當參數(shù)為f ber 1e-4的時候運行效果如下：該程序存在的主要問題就在于會反復重傳未被確認的幀，造成了信道資源的浪費，這可以在實驗的結果中看出，在進行較長時間的運行后，信道流量水平趨于平穩(wěn)，此時的數(shù)據(jù)和理論之大致相當，說明

17、所確認的問題確實是癥結所在。只要能限制其反復重傳，就能提高信道利用率。11.5 研究和探索的問題前面列出的“可研究和探索的問題”，有哪些問題你有了答案或者自己的見解？給出你的結論，并詳細闡述你的理由或見解。1. CRC 校驗能力CRC校驗碼的檢錯能力很強，它除了能檢查出離散錯外，還能檢查出突發(fā)錯，CRC校驗碼具有以下檢錯能力：CRC校驗碼能檢查出全部單個錯；CRC校驗碼能檢查出全部離散的二位錯；CRC校驗碼能檢查出全部奇數(shù)個錯；CRC校驗碼能檢查出全部長度小于或等于K位的突發(fā)錯；CRC校驗碼能以1-（1/2）K-1的概率檢查出長度為（K+1）位的突發(fā)錯。2. 軟件測試方面的問題(1)驗證所完成

18、的程序能否在各種情況下都能夠正確工作，是軟件測試環(huán)節(jié)的主要目的。(2)表3 中列出了七種測試方案，設計這么多種測試方案的目的是檢測此程序在不同信道條件下的傳輸性能。-u是測試成幀方案的效率。無參數(shù)時模擬在實際線路中，不連續(xù)的收發(fā)時的傳輸性能。-f用于測試信道滿負荷時的傳輸性能。-l,-e,-s用于測試在特殊情境下傳輸性能。-ber可以改變誤碼率，從而檢驗無差錯傳輸?shù)慕研约靶阅堋?1.6 實驗總結和心得體會如果一切100%順利，編輯的程序一次編譯就通過，運行一次就正確，那么完成本次實驗的代碼編寫和調試工作大約需要46 個小時。你花的時間超過了這個預測嗎？描述在調試過程中都遇到了哪些問題和解決的

19、過程。(1) 完成本次實驗的實際上機調試時間是多少？五天，總共約十五個小時。(2) 編程工具方面遇到了哪些問題？包括Windows環(huán)境和VC軟件的安裝問題。無。(3) 編程語言方面遇到了哪些問題？包括C語言使用和對C語言操控能力上的問題。實驗中數(shù)據(jù)幀采用了字符數(shù)組這種數(shù)據(jù)結構，在函數(shù)調用時會用到數(shù)組的形參表示，由于需要改變數(shù)組的值，此時傳送的是數(shù)組首地址，屬于傳引用調用。(4) 協(xié)議方面遇到了哪些問題？包括協(xié)議機制的設計錯誤，發(fā)現(xiàn)協(xié)議死鎖，或者不能正確工作，協(xié)議參數(shù)的調整等問題。在確定成幀方案時，有兩種可以實現(xiàn)的方案：一種是先給數(shù)據(jù)加CRC校驗碼，再添加ESC字符成幀 ；另一種是先給數(shù)據(jù)加ESC，再CRC校驗，再給CRC加ESC。其中后者先給數(shù)據(jù)加操作實現(xiàn)較為復雜，但其檢錯性能更好，前者處理較為簡單，但檢錯性能稍弱.我們將兩種方法均加以實現(xiàn)之后，發(fā)現(xiàn)實際的效果差別不大，為了代碼簡介以及減少不必要變量的使用，我們在最終的程序中使用了先加ESC后CRC校驗方法。(6) 總結本次實驗，你在C 語言方面，協(xié)議軟件方面，理論學習方面，軟件工程方面等哪些方面上有所提高？在這次實驗過程中，我們遇到了較多困難