NACK contre ACK? Quand utiliser l'un sur l'autre?

Personnellement, je ne pense même pas qu'il y ait un besoin d'ACK. C'est plus rapide si nous envoyons simplement NACK (n) pour les paquets perdus au lieu d'envoyer un ACK pour chaque paquet reçu. Alors, quand / quelles situations utiliserait-on ACK sur NACK et vice-versa?

La raison de l'ACK est qu'un NACK n'est tout simplement pas suffisant. Disons que je vous envoie un flux de données de segments X (disons 10 pour plus de simplicité).

Vous êtes sur une mauvaise connexion et ne recevez que les segments 1, 2, 4 et 5. Votre ordinateur envoie le NACK pour le segment 3, mais ne se rend pas compte qu'il devrait y avoir des segments 6-10 et ne les NACK pas.

Donc, je renvoie le segment 3, mais mon ordinateur croit à tort que les données ont été envoyées avec succès.

Les ACK fournissent une certaine assurance que le segment est arrivé à destination.

Si vous souhaitez que l'application traite l'ordre des données et les retransmissions, vous pouvez simplement choisir d'utiliser un protocole comme UDP (par exemple, comme le fait TFTP).

Tout se résume à la distribution de probabilité de perte et au modèle de trafic.

Prenons par exemple une liaison sans fil typique, avec un taux de perte constant de 10 à 30%. Si vous acquittez chaque trame reçue (comme 802.11abg), vous détecterez rapidement quand une trame a été perdue, vous ne perdrez donc pas de temps à attendre un délai.

Si vous deviez NAK à la place, vous deviendrez dépendant du modèle de trafic: - Si vous envoyez un seul paquet de demande et attendez une réponse, et que cette demande est perdue, vous devrez avoir un délai qui expire si vous n'obtenez pas de répondre. - Si vous envoyez simplement un flux de paquets à un destinataire principalement muet, il est acceptable de ne recevoir un NAK que lorsque le destinataire reçoit le prochain paquet ou plus. Mais cela signifie que le destinataire doit réorganiser les paquets et que l'expéditeur doit garder une trace d'un important arriéré de messages qu'il a envoyé.

(devinez quelle solution 802.11n choisir? les deux. Le récepteur envoie une image bitmap de longueur variable des trames qu'il a reçues)

Prenons maintenant un réseau Internet typique: vous avez près de 0% de perte de paquets, jusqu'à ce que quelque chose de mauvais se produise, et vous avez une perte de paquets proche de 100% pendant un certain temps suivant une loi de distribution exponentielle, d'une interruption de 200 ms à une minute et un moitié.

Accepter chaque paquet semblerait inutile dans un réseau sans perte, jusqu'à ce que vous considériez le cas où le lien est rompu: vous ne recevrez pas ACK ou NACK pendant une durée éventuellement prolongée, et le récepteur n'enverra généralement rien avant le lien est restauré.

Si vous utilisez ACK, l'expéditeur cessera d'envoyer et conservera son carnet de commandes jusqu'à ce que le lien soit restauré. Si vous utilisez NACK à la place, le récepteur peut éventuellement vous dire qu'il n'a pas reçu le paquet qui est tombé du carnet de commandes de l'expéditeur depuis longtemps, et la connexion est essentiellement irrécupérable.

Les ACK sont utiles dans les protocoles de fenêtre coulissante, ils permettent au transmetteur A de savoir que les données envoyées ont été reçues par la télécommande B.L'émetteur A peut alors continuer à envoyer les données suivantes - jusqu'à ce que sa fenêtre de transmission soit pleine (de données envoyées à la télécommande mais pas encore reconnu).

Les ACK peuvent être considérés comme plus essentiels que les NAK. Les NAK permettent simplement une récupération plus rapide , dans le cas où un paquet / bloc envoyé par A n'est pas reçu par B, et B détecte en quelque sorte qu'un paquet / bloc est manquant.

Il est parfaitement possible de concevoir un protocole prenant en charge un transfert et un contrôle de flux fiables uniquement avec ACK, sans NAK (avec retransmission par l'émetteur dans le cas où l'émetteur ne reçoit pas d'ACK, mécanisme de retransmission qui est nécessaire dans tous les cas).

Une chose la plus importante que je voudrais ajouter ici, dans TCP, nous N'ENVOYONS PAS ACK pour CHAQUE PAQUET RECU.

Cependant, les ACK sont envoyés uniquement pour le DERNIER PAQUET REÇU.

S'il vous plait corrigez moi si je me trompe.