數據鏈路層滑動窗口協議設計與實現試驗匯報一、試驗任務及內容利用所學數據鏈路層原理,設計一個滑動窗口協議并在仿真環境下編程實現有噪音信道環境下可靠雙工通信。信道模型為8000bps全雙工衛星信道,信道傳輸時延270毫秒,信道誤碼率為10-5,信道提供字節流傳輸服務,網絡層分組長度在240~256字節范圍。實現有噪音信道環境下無差錯傳輸。運行程序并檢驗在信道沒有誤碼和存在誤碼兩種情況下信道利用率。提升滑動窗口協議信道利用率,依據信道實際情況合理地為協議配置工作參數,包含滑動窗口大小和重傳定時器時限以及ACK搭載定時器時限。試驗環境Windows7環境PC機,MicrosoftVisualC++6.0集成化開發環境二、協議設計協議分層結構及層服務:包含物理層,數據鏈路層和網絡層三層。該試驗關鍵設計數據鏈路層協議,為實現有噪聲環境下高信道利用率傳輸,我們采取回退n幀（gobackn）技術協議。發送方窗口大小為31;經過捎帶確定來完成可靠數據通信;出現信道誤碼造成收幀犯錯時,接收方丟棄全部后續幀,待定時器超時后發送方重發。該層提供服務:從網絡層接收要發送數據包,將之分拆成數據幀;按一定成幀方案完成份幀,加校驗碼,加ack等操作;進行合適流量判定和擁塞控制;開啟定時器將之傳輸給物理層。數據幀經信道傳送給接收方,接收方數據鏈路層實施與成幀相逆操作;處理ack信息,終止定時器（或開啟ack定時器,ack成幀傳送）;判定是否為欲接收數據,數據是否犯錯,提交給網絡層。退回N步工作原理示意圖:試驗所形成幀(成幀方案):DATAFramen+=========+========+========+===============+========+|KIND(1)|ACK(1)|SEQ(1)|DATA(240~256)|CRC(4)|+=========+========+========+===============+========+ACKFrame+=========+========+========+|KIND(1)|ACK(1)|CRC(4)|+=========+========+========+NAKFrame+=========+========+========+|KIND(1)|ACK(1)|CRC(4)|+=========+========+========+CRC校驗和多項式定義:此次試驗采取CRC校驗方案為CRC-32,與IEEE802.3以太網校驗和生成多項式相同。生成多項式為:x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x1+1校驗和附加在數據幀尾部,接收方用帶校驗和數據來邏輯除以生成多項式,余數為零則數據無誤碼,反之有誤碼等候發送方重傳。可靠通信和誤碼控制方案:經過捎帶確定來完成可靠數據通信;出現信道誤碼造成收幀犯錯時,接收方丟棄全部后續幀,此時發送方長久接收不到確定信息,引發定時器超時后發送方重發;接收方無數據傳送造成發送方無法收到捎帶確定時,接收方確定定時器超時,結構一確定幀單獨傳送。三、軟件設計給出程序數據結構,模塊之間調用關系和功效,程序步驟。此次試驗我們對go-back-N協議進行了編寫,描述以下:數據結構:typedefenum{false,true}boolean;//blooleantypetypedefunsignedcharseq_nr;//sequenceoracknumberstypedefunsignedcharpacket[PKT_LEN];//用數組存放數據/*FRAMEkind*/#defineData1#defineAck2#defineNak3staticintphl_ready://物理層狀態next_frame_to_send;//MAX_SEQ>1;usedforoutboundstream,andinitianizenextframegoingoutack_expected;//oldestframeasyetunacknowledged,andinitianizenextackexpectedinboundframe_expected;//nextframeexpectedoninboundstream,andinitializenumberofframeexpectedinboundbuffer[MAX_SEQ+1];//buffersfortheoutboundstreamnbuffered;//outputbufferscurrentlyinuse,andinitiallynopacketsarebufferedbufferLen[MAX_SEQ+1]//bufferLen存放每個buffer中數據有效長度typedefstruct{//幀結構 unsignedcharkind;seq_nrack;seq_nrseq;packetinfo;unsignedcharcrc[4];}frame;模塊結構:給出程序中所設計子程序完成功效,子程序每個參數意義。A)staticbooleanbetween(seq_nra,seq_nrb,seq_nrc)//判定b是否是在a、c之間幀B)staticvoidput_frame(unsignedchar*frame,intlen)//crc編碼并向物理層發送C)send_data(unsignedcharkind,seq_nrframe_nr,seq_nrframe_expected,packetbuffer[],intdlen[])//生成幀D)intmain()//主函數,分為五個事件(1)NETWORK_LAYER_READY,事件發生后從網絡層讀數據,成幀;若目前物理層可用,發送。(2)PHYSICAL_LAYER_READY,事件發生后,若有未發送幀,發送,不然置物理層狀態為可用。(3)DATA_INCOMING,事件發生后,來了arg個字節數據,每接收一個數據,判定是否為幀尾;若為幀尾,提取一幀,去掉填充,進行校驗;若校驗結果正確,處理ack,然后處理數據。接收完arg個字節,跳出。(4)ACK_TIMEOUT,事件發生后,產生一個不含數據ack幀,等候直到物理層有效,發送。(5)DATA_TIMEOUT,事件發生后,重發ack_expected和next_frame_to_send之間幀。算法步驟:畫出步驟圖,描述算法關鍵步驟。結束發送完成否數據幀是否丟失A生成幀并發送,B接收幀,并返回信息是是回退重傳否連接是否成功新建A、B兩站自動連接開始結束發送完成否數據幀是否丟失A生成幀并發送,B接收幀,并返回信息是是回退重傳否連接是否成功新建A、B兩站自動連接開始四、試驗結果分析(1)描述你所實現協議軟件是否實現了誤碼信道環境中無差錯傳輸功效此協議軟件實現了誤碼信道環境中無差錯傳輸功效(2)程序健壯性在較低誤碼率信道條件下,該程序運行平穩,未出現任何差錯,健壯性良好,在高誤碼率信道條件下,程序運行有時會出現中止,但大多數時候均運行超出二十分鐘以上,故本程序健壯性良好,但仍有值得改善之處。(3)協議參數選擇:滑動窗口大小為7,重傳定時器時限,ACK搭載定時器時限為300。在go_back_n協議中（假設接收方一直有數據發送,即無ack定時器超時現象）,滑動窗口大小M,信道傳輸時延a,發送速率c,幀大小f在滿足以下關系時信道利用率（M*(f/c)/[2a+2(f/c)]）靠近100%:M>=[2a+2*(f/c)]/（f/c）;因為實際數據傳送很可能在某段時間類接收方無數據反送,包含ack幀單獨傳送問題,故通常信道利用率不可能達成100%,但M選擇最少要滿足公式。至于預防M過大問題,可經過實際測試結果分析來得到適宜M值。滑動窗口大小選擇直接包含到信道利用率和數據擁塞問題;若太小,會造成信道空閑,利用率很低;若太大,數據發送過快,會造成接收方數據鏈路層來不及處理,數據物理層及信道發生擁塞現象造成數據丟失,犯錯率增大,重傳率高。8000kbps信道發送256字節幀需要256*8/8000=256ms（256+270*2）/256=3.X,最大窗口應該7就行了.重傳定時器大小由發送速率、信道時延及接收方發送頻率等確定,太小會頻繁重發,太大也會降低信道利用率。結合多項測試最終定為ms。ack搭載定時器時限由本站發送頻率決定,首先,為了節省帶寬應該盡可能搭載使用。其次當本站長時間無數據發送時應該盡可能早點發送ack幀。經過數項測試,定位300ms。(4)理論分析:無差錯條件下分組層能取得最大信道利用率應該是256/262*100%=97.7,而在誤碼率為1e-5情況下應為256/262（1+262*8*0.00001）=95.5。(5)試驗結果分析:你程序運行實際達成了什么樣效率,比對理論推導給出結論,有沒有差距？給出原因。有沒有改善措施？假如沒有時間把這些方法付諸編程實施,介紹你方案。序號命令說明運行時間(秒）效率(%)備注AB1datalinkaudatalinkbu無誤碼信道數據傳輸1957.41352.5896.972datalinkadatalinkb站點A分組層平緩方法發出數據,站點B周期性交替“發送100秒,停發100秒”1525.15648.5787.693datalinkafudatalinkbfu無誤碼信道,站點A和B分組層都洪水式產生分組1586.40996.9796.974datalinkafdatalinkbf站點A/B分組層都洪水式產生分組1899.68885.7985.805datalinkaf–ber1e-4datalinkbf–ber1e-4站點A/B分組層都洪水式產生分組,線路誤碼率設為10-41028.14938.0838.60試驗結果離預期效果存在差距,尤其在有誤碼條件下,信道利用率與理論之相比相差很大。原因有多個方面:填充字節和發送時候延遲,這首先無法縮短;信道空閑,只是因為窗口大小、重傳定時器時限和ACK搭載定時器時限選擇不是很合適,這方面,需要多做測試來確定發送端、接收端延時,再確定具體數值;另外,ack發送可能有些滯后,沒有一個非常合剪發送機制。還有一點,從網絡層受到數據后,我是把數據成幀后存起來,現在看來,考慮到ack更新,在發送時再成幀更有效率些。(6)存在問題:在“表3性能測試統計表”中給出了7種測試方案,在測試中你程序有沒有失敗,或者,雖未失敗,但表現出來性能仍有差距,你程序中還存在哪些問題?測試中沒有失敗,不過性能差距挺大。關鍵是超時時限和窗口大小問題。五、研究和探索問題1．start_timer()不是在開啟時就計時,而是在物理層發送了才開始計時;相對,start_ack_timer()是以開啟就開始計時。前者要考慮發送緩沖區等候時間,以后者考慮是ack是否被裝到了幀上。2．重傳時限設定得比較長,大部分情況下都不會超時。實踐證實,這種情況下效率相對更高一點。3．流量控制方面,首先窗口大小能夠控制。然后發送和接收緩存區大小也限制了流量。六、試驗總結和心得體會(1)完成此次試驗實際上機調試時間是多少？三天,第一天花了大約7小時討論程序結構以及函數調用,第二天完成編程并調試,第三天寫文檔和性能測試,(2)編程工具方面碰到了哪些問題？包含Windows環境和VC軟件安裝問題。該試驗要用vc++6.0,而且要在doc系統運行生成exe文件。(3)編程語言方面碰到了哪些問題？包含C語言使用和對C語言操控能力上問題。大約沒碰到什么問題。。碰到只是部分函數調用上。(4)協議方面碰到了哪些問題？包含協議機制設計錯誤,發覺協議死鎖,或者不能正確工作,協議參數調整等問題。成幀時,開始我們幀結構是(ack幀序號數據長度數據內容校驗和),長度在256時成了0,以后在成幀時去掉了數據長度這項。(5)開發庫方面碰到了哪些問題？包含庫程序中BUG,庫函數文檔不夠清楚造成誤解,庫函數設計在所提供功效結構上缺憾造成編程效率低下。這些問題或提