這是我在看相關的ARQ(StopAndWait, GoBackN, SelectiveRepeat)產生的疑問
為了簡單描述我的問題, 我用StopAndWait來舉例
假設有個Stop-And-Wait的傳輸情形像這樣
有端點A跟B在傳輸, 視窗大小只有2, 橫軸是時間軸, 斜線代表網路傳輸
下面這個是A跟B之間在通訊的示意圖
┌──┬──────────────────┐
│端點│ 封包編號 │
│ A │ [0]　[1]　[0]　[1]　[0]　..... │
│　 │ 　＼　＼　　＼　＼　　＼ │
│ B │ [0] [1] [0] [1] [0] ... │
└──┴──────────────────┘
我想請問有沒有可能發生這樣的狀況
┌──┬──────────────────┐
│端點│ 封包編號 │
│ A │ [0]　[1]　[0]　[1]　[0]　..... │
│　 │ │＼　 │
│ │ │ ＼ │
│ │ │ ＼ 第2次(timeout重送) │
│ │ │ ＼ │
│ │ │第1次 ＼ │
│ │ ＼ ＼ │
│ B │ [0] [1] [0] [1] [0] ... │
└──┴──────────────────┘
也就是因為第1個[0]傳輸了比較久
不過B還是順利接收到第1個[0]
然後也順利收到之後的[1] (為了圖面乾淨, 我把[1]的傳輸線省略)
但因為之前的第1個[0]太久沒收到回應
所以造成A當時timeout重送
而B在收到[1]之後, 也順利收到這個重送的封包
也就是B總共收到兩次第1個[0]的封包
而且很剛好的“照順序”收到
這樣不會有問題嗎?
還是有什麼沒考慮到的狀況, 所以根本不會發生呢?
謝謝

你這樣兩邊窗口都是2 就不適用stop and wait了吧 接受窗口要2的話應該就要用selctive repeat 不然這樣應該會產生混淆的問題 stop and wait,go back n的接受窗口應該都是只有1的而且你stop and wait再還沒收到序號0的ack 應該不會再接著傳序號1的資料的 也就是傳送方在送出序號0的情況下應該是進入一種封閉的狀況 要等收到確ack1才可以在進入下個傳輸我大概懂你的意思了 只是要達到你說的情形機率真的不高吧 要發生這樣的情況要兩個前提 你的序號一定要很小 而且還要你的序號0的封包很慢抵達 而且後面的又要先抵達感覺好像挺奇怪的 @@ 還有我主要是根據forouzan這本書的觀念來判斷的

看起來j大也認為 只是要序號很小 又各種巧合碰在一起的確有可能發生 那上面的推測應該沒錯.. 感謝j大的意見

收到封包1應該要回NAK0，要求封包0重送沒有NAK的話就是等timeout，那你的序號太少