關於滑動視窗的小小小tip

關於滑動視窗的小小小tip

@(電腦網路)

如果提出來一個結論：視窗大小 = 發送視窗大小+接收視窗大小。

不知道會多少人覺得這是在幹啥。

對於n位元編號的資料幀，曾經討論過， 發送視窗+接收視窗≤2n 發送視窗+接收視窗 \leq 2^n時可以區分新舊輪次。

http://blog.csdn.net/u011240016/article/details/52653923?locationNum=2&fps=1

這篇記錄了一點點那天晚上挺煎熬的思考，因為找不到合適的論據，也沒有足夠的抽象能力抽出這樣的結論，所以只能猜測，後來想明白就是這樣。

那麼理解了區分新舊輪次的計算式，就很容易理解本文最上面提出的結論，但是這也是很容易被忽視的點，認為發送視窗和接收視窗天各一方，愛誰誰，有啥關係。實際二者大小此消彼長，共用n位元編出的離散狀態作為自己的視窗資料編號。

有這些，就可以愉快的判斷下面的幾個結論了。

I. 對於視窗大小為n的滑動視窗，最多可以有n幀已經發送但是沒有確認。
II. 假設幀序號有3位，採用連續ARQ協議，發送視窗的最大值是4.
III. 在GBN協議中，如果發送視窗大小是16，則至少需要4位序號才能保證協議不出錯。 全是錯的，你能信。

分析：視窗大小，嗯，不是發送視窗。接收視窗至少是1吧，發送視窗最大時n-1,最多，頂天了只能連續發送n-1個幀。I,妥妥地錯。概念挖坑。
3位，離散狀態有8個，連續ARQ，可以的，讓接收視窗最小，為1.發送視窗將獨佔7個狀態，大小為7。II,妥妥地錯。
GBN，回退n幀，n是發送視窗的大小。為什麼要回退n幀。接收慢唄。一次只能接收一個（接收視窗為1），一旦出錯就要GBN回退n，重新來。 2n≥16+1→n=5(at least) 2^n \geq 16+1 \rightarrow n = 5(at\ least). III.妥妥地錯。

於是我想：

有些貌似正確的錯誤。

有些正確的廢話。

都是需要過濾的。