設計可靠數據傳輸協議
SW0協議
信道不丟包
解決方案：
接到正確PKT，發送一個肯定確認(ACK)
收到錯誤PKT，發送一個否定確認(NAK)，重傳原PKT
停止等待(stop-and-wait, SW)協議
實用中有不少漏洞
SW1協議
信道丟包:
SW0的發送方會一直等待ACK，引起協議死鎖
解決方案：
增加超時定時器
每發PKT，啓動超時定時器，稱爲超時重傳機制
重傳時間略大於RTT
SW2協議
確認分組丟失:
出現了分組冗餘的差錯
解決方案：
增加一種新機制：發送序號
序號空間要較小
如發送序號3 bit，在0~7間循環使用
SW3協議
發送方過早超時:
收到重複的確認，無法分辨對應哪個分組
解決方案：
增加確認序號機制，分辨出確認對應哪個分組
綜合以上機制爲SW協議，或自動重傳請求(ARQ)
設計可靠數據傳輸協議機制：
差錯檢測、接收方確認(肯定/否定)、重傳、定時器和序號(數據和確認)
二.流水線協議
流水線: 發送方允許發送多個、傳輸中、未應答的分組
必須增加序號範圍
發送方和/或接收方設有緩衝
兩種流水線協議:
回退N步（go-Back-N）, 選擇性重傳（S-R）
流水線: 提高協議利用率,如下圖：
處理流水線差錯
處理停等協議出現差錯時，需要多種機制
當流水線差錯時，對所需序號窗口和緩衝的要求取決於數據傳輸協議處理丟失、損壞及時延過大分組的方式
恢復流水線差錯的兩種基本方法
回退N步(Go-Back-N，GBN)
選擇重傳(Selective Repeat, SR)
回退N步協議(Go-Back-N)
- 發送方:
在分組首部需要K比特序號，2k=N
“窗口”最大爲N, 允許N個連續的沒有應答分組 - ACK(n): 確認所有的（包括序號n）的分組 - “累計ACK”
可能收到重複的ACK
對每個傳輸中的分組用同一個計時器 - timeout(n): 若超時，重傳窗口中的分組n及所有更高序號的分組
注：
接收方根據滑動窗口的序號按序接收分組窗口內連續
窗口中失序分組及後面將被丟棄後面可能正確收到多個
發送方採用超時機制來重傳出現丟失或差錯的分組
接收方採用累積確認的方式可以不一一確認
GBN協議的接收窗口的長度爲1
選擇性重傳(Selective Repeat)
問題：GBN是否還能夠改善？(單一差錯可能導致大量不必要重傳)
接收方分別確認所有正確接收的報文段緩存分組, 以便最後按序交付給上層。發送方只需要重傳沒有收到ACK的分組
發送方定時器對每個沒有確認的分組計時
發送窗口：N個連續的序號
也需要限制已發送但尚未應答分組的序號
選擇性重傳算法
窗口長度問題
例子:
序號: 0, 1, 2, 3
窗口長度 = 3
接收方：在(a)和(b)兩種情況下，接收方沒有發現兩者間的差別!
在 (a)中不正確地將冗餘的當新的，而(b)中不正確地將其當作冗餘的
序號長度與窗口長度的關係：
窗口長度小於等於序號空間的一半
用途小結
