asmod napisał(a):
wydaje mi się że przy takim właśnie zegarze nie jest potrzebna szybka transmisja
Masz kolego zupełną rację "wydaje ci się"
zegar i szybka transmisja ?
po co ? na co ? do czego ? co pan chcesz tak szybko transmitować ?
... to typowe nieporozumienie i niezrozumienie UDP przez wielu ludzi, którzy nie mają na co dzień do czynienia z programowaniem w oparciu o takie protokoły. I dlatego później wszędzie piszą takie z kolei rzeczy :
asmod napisał(a):
, UDP nie gwarantuje kolejności/dotarcia pakietu więc co gdy pakiet od serwera czasu dojdzie uszkodzony?
Coś wiesz o tym UDP ale to bardziej na zasadzie jak z przysłowia "wiadomo, że biją dzwony ale nie wiadomo w jakim kościele"
więc doprecyzuję żebyś wiedział w czym rzecz ok?
Najpierw MITY i BAJKI którymi straszą się ludzie nawzajem w internecie (jak poczytać nieraz różne wypowiedzi)
- UDP jest zawodnym protokołem bo:
1. nie gwarantuje że wysłany DATAGRAM dotrze (Uwaga Datagram a nie pakiet - to jest różnica - zaraz wyjaśnię)
2. nie gwarantuje że wysłane datagramy gdy jest ich kilka np 3 - dotrą na drugą stronę w tej samej kolejności jak zostały wysłane
3. DATAGRAM może mieć MAKSYMALNIE 1024 bajty
Boże! toż jak się to poczyta to w zasadzie tylko wziąć nogi za pas i uciekać gdzie pieprz rośnie , splunąć przez lewe ramię i na psa urok z tym UDP. Lepiej wziąć TCP czyli protokół gniazdkowy
który nie ma takich wad
Tymczasem teraz uwaga! .... owszem te bajki o tym, że pakiety UDP nie docierają do miejsca docelowego, że docierają w innej kolejności itp itd - można w dzisiejszych czasach sobie między bajki włożyć
Tak było w zamierzchłych czasach gdy jeszcze były sieci w oparciu o kable koncentryczne BNC itp gdzie awarie sprzętowe sieci były na porządku dziennym
Dzisiaj ? .... dzisiaj panie to protokół UDP wykorzystuje się prawie wszędzie - rozejrzyj się - zajrzyj w wiresharka, sprawdź w oparciu o jakie protokoły działają np praktycznie WSZYSTKIE gry sieciowe
ale też mnóstwo innych programów
Reasumując - jest to lekki i wydajny protokół wręcz IDEALNIE nadający się do zastosowań z tak małymi prockami
nie ma narzutu obsługi gniazdek .... w związku z tym odpada ci np w procku pooling gdy korzystasz ze stosu TCP w procku. Przesyła się zwykle niewielkie ilości danych rzadko albo prawie nigdy nie przekraczające rozmiaru DATAGRAMU
.... nie składa się datagramów w pakiety - chociaż jak się uprzeć to też można
i kontrolować ich kolejność tylko znowu po co ?
Z drugiej strony - oprogramowanie zadań sieciowych w oparciu o UDP jest wbrew pozorom dużo dużo prostsze i daje duże pole do popisu
Próba porównywania tutaj szybkości UDP do TCP jest już kompletnie bez sensu - więc o tym to nawet nie ma co dyskutować
z kolei nie ma takich sytuacji jak pisałeś wyżej:
asmod napisał(a):
więc co gdy pakiet od serwera czasu dojdzie uszkodzony?
Datagram kolego nie dojdzie uszkodzony
... albo dojdzie w 100% poprawny albo go w ogóle nie zobaczysz bo niższe warstwy stosu TCP go odrzucą (zajrzyj do modelu OSI stosu TCP i sprawdź na czym "jeżdżą" datagramy
i co i kto odpowiada za ich integralność. To właśnie dzięki temu komunikacja UDP jest nawet szybsza w wielu przypadkach
asmod napisał(a):
zakładam że synchronizacja z serwerem czasu nie jest wykonywana co pare sekund ;p, tylko po np. braku zasilania
Źle zakładasz
synchronizacja jest wykonywana co ileś godzin (zresztą można to konfigurować) ... A gdy nie zdarz się, że nie dotrze odpowiedź to zapytanie wysyłane jest częściej a tu - aż do skutku.
Na koniec podpowiem - że akurat w tym konkretnym przypadku z uwagi na użyty moduł ATNEL-WIFI232-T, który to posiada wbudowany stos TCP i procesor nawet się nie orientuje - że gada z NTP po ethernecie WIFI
.... to byłoby totalnie obojętne czy użyty zostałby TCP czy UDP
.... ale wybrany został UDP bo z niego się korzysta ZAWSZE TAM, gdzie nie trzeba koniecznie korzystać z połączeń gniazdkowych TCP
tyle mogę powiedzieć
mam nadzieję, że teraz jaśniej
Kanał - ATNEL tech-forum
Zaloguj
Zarejestruj
Informacje o cookies
FAQ
Szukaj
