Pourquoi la taille de la fenêtre est-elle inférieure ou égale à la moitié du numéro de séquence dans le protocole SR?
Dans le protocole de répétition sélective, la taille de la fenêtre doit être inférieure ou égale à la moitié de la taille de l'espace de numéro de séquence pour le protocole SR. Pourquoi est-ce ainsi et comment?
Cela évite que les paquets ne soient pas reconnus correctement.
Si la taille de la fenêtre est supérieure à la moitié de l'espace du numéro de séquence, si un accusé de réception est perdu, l'expéditeur peut envoyer de nouveaux paquets que le destinataire considère comme des retransmissions.
Par exemple, si notre plage de numéros de séquence est 0-3 et la taille de la fenêtre est 3, cette situation peut se produire.
A -> 0 -> B
A -> 1 -> B
A -> 2 -> B
A <- 2ack <- B (c'est perdu)
A -> 0 -> B
A -> 1 -> B
A -> 2 -> B
Après le paquet perdu, B s'attend maintenant à ce que les paquets suivants portent les numéros de séquence 3, 0 et 1.
Mais, le 0 et le 1 que A envoie sont en fait des retransmissions, donc B les reçoit hors service.
En limitant la taille de la fenêtre à 2 dans cet exemple, nous évitons ce problème car B en attend 2 et 3, et seules les 0 et 1 peuvent être des retransmissions.
L'espace de séquence est remis à zéro après que le nombre maximum a été atteint. Considérez le cas de coin où tous ACK sont perdus - l'expéditeur ne déplace pas sa fenêtre, mais le destinataire le fait (car il ne sait pas que l'expéditeur ne reçoit pas les ACK). Si nous ne limitons pas la taille de la fenêtre à la moitié de l'espace de la séquence, nous nous retrouvons avec un expéditeur chevauchement "envoyé mais non accusé" et un destinataire "valide de nouveaux" espaces de séquence. Cela aurait pour conséquence que les retransmissions seraient interprétées comme de nouveaux paquets.
Parce que le destinataire ne fera pas la distinction entre un vieux paquet et un nouveau paquet. Le récepteur identifie les paquets sur la base de numéros de séquence, et il existe un nombre fini de numéros uniques pour chaque connexion. Vous ne pouvez pas avoir un tampon infini.
Regardons un scénario d'échec évident:
La taille de la fenêtre est supérieure à l'espace du numéro de séquence. Disons que nous avons les numéros de séquence 0, 1, 2. Et la taille de notre fenêtre est 4. Cela signifie que la fenêtre a deux occurrences de 0.
0,1,2,0 <- modulo wrap. Lorsque nous obtenons un paquet avec une seq de 0. Est-ce le premier paquet ou le quatrième? Aucune idée. Maintenant, ce problème se produira dans la mesure où la taille de la fenêtre est supérieure à la moitié de l’espace des numéros de séquence. Pourquoi? Parce qu'il y a toujours la possibilité que le destinataire regarde un numéro de séquence qui PEUT être contenu dans un paquet provenant de l'expéditeur qui est NEW ou OLD. Cela arrive-t-il toujours? Non, mais quand c'est le cas, voici ce qui se passe:
Cas 1:
Fenêtre du récepteur après la réception correcte des paquets 0,1,2. 0,1,2, [3,0,1], 2 Mais que se passe-t-il si les ACK envoyés sont perdus? Eh bien, l'expéditeur renverra 0,1,2. Mais sont 0,1 vieux ou nouveau? Le récepteur ne peut pas dire.
Cas 2:
Même fenêtre à la réception. Les trois paquets sont reçus.
0,1,2, [3,0,1], 2
Maintenant, le récepteur reçoit TOUS les acks sauf UN correctement. Permet de choisir le 2ème (1). Maintenant, il va renvoyer 1. Mais le récepteur regarde 1! Alors est-ce le nouveau comme il l’attend (le nope), ou l’ancien?
Par conséquent, pour s'assurer que la fenêtre ne s'attend jamais à des numéros de séquence pouvant être utilisés par des paquets en attente potentiels (provenant d'une transmission normale ou d'une retransmission d'un accusé manquant), nous devons réduire la taille de la fenêtre ou augmenter le nombre de séquences.
Regardez ce qui se passe lorsque nous augmentons l’espace du numéro de séquence à 6.
0,1,2,3,4,5.
Peu importe la façon dont nous positionnons la fenêtre, nous ne risquons jamais de recevoir un paquet avec un ancien numéro de séquence.
0,1,2, [3,4,5] 0,1 ...
Au moment où la fenêtre se termine, nous sommes convaincus que nous avons reçu les précédents dans l’ordre.
Ce lien contient une animation qui parcourt chacune des étapes du protocole pour expliquer pourquoi la taille de la fenêtre est importante:
http://webmuseum.mi.fh-offenburg.de/index.php?view=exh&src=73
Fondamentalement, si la taille de la fenêtre est trop élevée, une corruption de la transmission peut alors générer des hypothèses incorrectes et entraîner une corruption des données dans le résultat final.