implementacja ack nad UDP?

Question

Mamy system (wbudowany w C), który wykonuje komunikację przez UDP. Ostatnio stwierdziliśmy konieczność zagwarantowania dostawy pakietów. Moje pytanie brzmi: jakie byłyby minimalne dodatki do systemu opartego na UDP, aby zapewnić dostawę przy użyciu pakietów ACK? Również idealnie bez konieczności manipulowania nagłówkami pakietów. Mamy kontrolę poziomu aplikacji nad pakietami, w tym numerami sekwencji i flagami ack/nack. Zastanawiam się, czy jest to utracona przyczyna i wszystko, co spróbujemy zrobić, będzie w zasadzie wadliwą i zepsutą wersją TCP. Zasadniczo istnieje minimalna poprawa, którą możemy wprowadzić, aby osiągnąć gwarantowaną dostawę (nie potrzebujemy wielu funkcji TCP, takich jak kontrola przeciążenia itp.). Dzięki!

Answer 1

Trudny problem. Powiedziałbym, że nie będziesz w stanie osiągnąć niezawodności TCP. Jednak rozumiem, że czasami trzeba mieć niezawodne UDP.

Gamedev forum

RUDP (nieco więcej Hardcore)

Old Thread about reliable UDP

Answer 2

Spójrz na rozdział 8 i działu 20 Stevena UNIX Network Programming, volume 1. Obejmuje wiele różnych podejść. Sekcja 20.5 "Dodawanie niezawodności do aplikacji UDP" jest prawdopodobnie najbardziej interesująca.

Answer 3

Mam pytanie z uruchomieniem here, które zbiera odpowiedzi na pytanie "Czego możesz użyć, gdy potrzebujesz niezawodnego UDP". Odpowiedzi są prawdopodobnie znacznie większe, niż chcesz lub potrzebujesz, ale możesz zapoznać się z niektórymi protokołami, które zostały zbudowane na UDP i pobrać tylko część ACK, której potrzebujesz.

Z mojej pracy z protokołem ENet (niezawodny protokół UDP), oczekuję, że potrzebujesz numeru sekwencyjnego w każdym datagramie UDP, sposób wysyłania potwierdzenia na otrzymane datagramy, sposób na utrzymanie datagramów, które wysłałeś, dopóki nie dostaniesz dla nich potwierdzenia ACK lub przekroczą limit czasu, a także sposób na odesłanie datagramów, na które jeszcze nie otrzymałeś potwierdzenia ACK ... Dodałbym również ogólny limit czasu, kiedy zdecydujesz że nigdy nie dostarczysz określonego datagramu i, jak sądzę, wywołania zwrotnego do twojej warstwy aplikacji, aby poinformować o tym niepowodzeniu dostarczenia ...

Answer 4

TCP przeplata 3 usługi, które mogą być istotne (OK, TCP robi dużo więcej, ale będę mówić tylko o 3.)

1. W zamówienie dostawy
2. Niezawodne dostawy
3. Sterowanie przepływem

Po prostu powiedział, że nie trzeba kontrolę przepływu, więc nawet nie będę adres że (jak można reklamować rozmiar okna itp., z tym że prawdopodobnie będziesz potrzebować okna. Dostanę się do tego.)

Powiedziałeś, że potrzebujesz niezawodnej dostawy. To nie jest zbyt trudne - używasz ACK, aby pokazać, że nadawca odebrał pakiet. Podstawowe niezawodne dostawy wygląda następująco:

1. Nadawca wysyła pakiet
2. odbiorca otrzymuje pakiet, a następnie wysyła ACK
3. Jeżeli nadawca nie dostaje ACK (w drodze timer), on wysyła ponownie pakiet.

tych trzech etapów nie rozwiązać te problemy:

1. Co jeśli ACK ginie?
2. Co się stanie, jeśli pakiety nie będą działać?

W związku z tym, twierdzisz, że potrzebujesz tylko niezawodnej dostawy - ale nie powiedziałeś nic o potrzebie ich zamówienia. Wpłynie to na sposób implementacji protokołu.

(przykład gdzie zamówienie nie ma znaczenia.. Jesteś kopiując rekordy pracowników z jednego komputera do drugiego, nie ma znaczenia czy jest odbierana płyta Alicji przed Bob, jak długo oboje tam dostać)

Wychodząc z założenia, że ​​potrzebujesz tylko niezawodnego (bo to właśnie powiedziałeś w swoim poście), możesz osiągnąć to na kilka sposobów.

Twój nadawca może śledzić niepotwierdzone pakiety. Jeśli więc wyśle ​​# 3, 4, 5 i 6 i nie otrzyma potwierdzenia za 3 i 4, to nadawca wie, że musi ponownie wysłać. (Chociaż nadawca nie wie, czy pakiety 3 i 4 były partiami, czy też ich ACK zostały utracone.) Tak czy inaczej, musimy dokonać retransmisji.)

Ale wtedy twój nadawca mógł wykonać zbiorcze potwierdzenie ACK - tak w powyższym przykładzie , byłoby to tylko potwierdzenie nr 6, gdyby otrzymało 3, 4 i 5. Oznacza to, że odbiorca spadłby o pakiet, gdyby nie otrzymał tych wcześniej. Jeśli twoja sieć jest bardzo niezawodna, może to nie być zła opcja.

Jednak opisane powyżej protokoły mają okno - czyli liczbę pakietów wysyłanych jednocześnie przez nadawcę? Co oznacza, że ​​potrzebujesz jakiegoś okna, ale nie w celu kontroli przepływu. Jak przesłać rozmiary okien?

Można to zrobić bez okna, albo mając stałą wielkość okna, albo wykonując coś w stylu stop-and-wait. Ta pierwsza może być lepszą opcją.

W każdym razie, nie odpowiedziałem bezpośrednio na twoje pytanie, ale mam nadzieję, że wskazałem kilka rzeczy, które warto wziąć pod uwagę podczas projektowania tego. Zadanie polegające na "niezawodnym przesyłaniu" bez części kontroli przepływu (np. Okien) i bez względu na to, że są w porządku, jest trudne! (Daj mi znać, jeśli powinienem podać więcej szczegółów na temat niektórych z tych rzeczy!)

Powodzenia!

Answer 5

Najlepszym sposobem na wdrożenie ack jest zrobienie go w warstwie aplikacji. CoAP jest przykładem protokołu aplikacji, który działa na udp, ale zapewnia niezawodny transfer danych. Zachowuje identyfikator wiadomości dla wszystkich komunikatów potwierdzających (CON) i wysyła odbiornik wysyła pakiet potwierdzenia z tym samym identyfikatorem wiadomości. Wszystkie pola potwierdzenia i wiadomości są przechowywane w części warstwy aplikacji. Jeśli więc nadawca nie otrzyma pakietu Ack z wysłanym przez niego komunikatem, przekaże ten pakiet. Programista aplikacji może modyfikować protokół w celu dostosowania go do potrzeb wymaganych do niezawodnego przesyłania danych.