NACK vs. ACK? Kiedy stosować jeden na drugim?

Osobiście nawet nie czuję potrzeby ACK. Jest to szybsze, jeśli wyślemy NACK (n) dla utraconych pakietów zamiast wysyłania ACK dla każdego odebranego pakietu. Więc kiedy / w jakich sytuacjach należy użyć ACK zamiast NACK i viceversa?

Powodem tego jest to, że NACK jest po prostu niewystarczający. Powiedzmy, że przesyłam Ci strumień danych z X segmentów (powiedzmy 10 dla uproszczenia).

Masz złe połączenie i odbierasz tylko segmenty 1, 2, 4 i 5. Komputer wysyła NACK dla segmentu 3, ale nie zdaje sobie sprawy, że powinny istnieć segmenty 6-10 i ich nie NACK.

Ponownie wysyłam segment 3, ale wtedy mój komputer fałszywie wierzy, że dane zostały pomyślnie wysłane.

Potwierdzenia są pewną pewnością, że segment dotarł do miejsca docelowego.

Jeśli chcesz, aby aplikacja zajmowała się kolejnością danych i retransmisjami, możesz po prostu wybrać protokół podobny do UDP (na przykład tak jak TFTP).

Wszystko sprowadza się do rozkładu prawdopodobieństwa strat i wzorca ruchu.

Weźmy na przykład typowe łącze bezprzewodowe ze stałym współczynnikiem strat 10–30%. Jeśli potwierdzisz każdą odebraną ramkę (jak 802.11abg), szybko wykryjesz utratę ramki, więc nie będziesz tracić czasu na oczekiwanie na przekroczenie limitu czasu.

Jeśli zamiast tego wybierzesz NAK, uzależnisz się od wzorca ruchu: - Jeśli wyślesz pakiet pojedynczego żądania i oczekujesz odpowiedzi, a żądanie to zostanie utracone, będziesz musiał mieć limit czasu, który upłynie, jeśli nie otrzymasz odpowiedź. - Jeśli wysyłasz strumień pakietu do przeważnie wyciszonego odbiorcy, dopuszczalne jest otrzymywanie NAK tylko wtedy, gdy odbiorca odbierze następny pakiet. Oznacza to jednak, że odbiorca musi zmienić kolejność pakietów i że nadawca musi śledzić dużą liczbę zaległych wiadomości, które wysłał.

(zgadnij, jakie rozwiązanie wybierze 802.11n? oba. Odbiornik wysyła otrzymaną mapę bitową o zmiennej długości ramek)

Teraz weź typową sieć internetową: masz prawie 0% utraty pakietów, aż stanie się coś złego, i masz prawie 100% utraty pakietów przez pewien czas zgodnie z wykładniczym prawem dystrybucji, od przerwy 200ms do minuty i pół.

Sprawdzanie każdego pakietu wydawałoby się bezcelowe w niestratnej sieci, dopóki nie rozważysz przypadku przerwania łącza: nie otrzymasz ACK ani NACK przez możliwie dłuższy czas, a odbiorca zazwyczaj nie wyśle ​​niczego, dopóki łącze nie zostanie zerwane został przywrócony.

Jeśli użyjesz ACK, nadawca przerwie wysyłanie i utrzyma zaległości, dopóki link nie zostanie przywrócony. Jeśli zamiast tego użyjesz NACK, odbiorca może ostatecznie powiedzieć ci, że nie odebrał pakietu, który spadł z zaległości nadawcy od dłuższego czasu, a połączenie jest w zasadzie niemożliwe do odzyskania.

Potwierdzenia ACK są przydatne w protokołach z przesuwanymi oknami. Pozwalają nadawcy A wiedzieć, że dane wysłane zostały odebrane przez zdalny B. Nadajnik A może następnie kontynuować wysyłanie kolejnych danych - do momentu zapełnienia okna transmisji (danych wysłanych do zdalnego, ale jeszcze nie potwierdzone).

ACK można uznać za bardziej istotne niż NAK. NAK po prostu pozwalają na szybsze odzyskiwanie , w przypadku, gdy pakiet / blok wysłany przez A nie jest odbierany przez B, a B w jakiś sposób wykrywa brak pakietu / bloku.

Całkowicie wykonalne jest zaprojektowanie protokołu obsługującego niezawodne przesyłanie i kontrolę przepływu tylko z ACK, bez NAK (z retransmisją przez Nadajnik w przypadku, gdy Nadajnik nie otrzyma ACK, mechanizm retransmisji, który jest potrzebny w każdym przypadku).

Jedną z najważniejszych rzeczy, które chciałbym tutaj dodać, w TCP, NIE wysyłamy ACK za KAŻDY OTRZYMANY PAKIET.

Jednak potwierdzenia są wysyłane tylko dla OSTATNIEGO OTRZYMANEGO PAKIETU.

Proszę, popraw mnie jeśli się mylę.