Kilka przemyśleń na temat mojego doświadczenia z TCP, UDP i MQTT, a także dodatkowe zasoby do przejrzenia.
W przypadku UDP napotkałem problem cichej awarii, w której aplikacja w jednym węźle sieciowym, kliencie, widzi tylko niektóre wysłane wiadomości UDP. Jest zbyt wiele powodów, dla których ruch sieciowy może się nie udać. Problem z UDP polega na tym, że pakiety można odrzucać praktycznie za każdym razem, gdy którykolwiek z węzłów na ścieżce sieciowej między producentem pakietów a konsumentem pakietów jest uzasadniony. Zobacz temat Wikipedii Utrata pakietów .
Pytanie brzmi, jaki jest twój wskaźnik strat w dowolnym kontekście sieci. Jeśli więc jest to komunikacja w sieci LAN lub podsieci, wskaźnik strat może być niski. W sieci WAN lub w Internecie wskaźnik strat może być dość wysoki. Pakiety UDP są odrzucane z wielu powodów i kierowane, jednak warunki sieciowe na to pozwalają przy zmniejszeniu liczby przeskoków. Wysyłanie pakietów w wielką pustkę bez odpowiedzialności pozostawia otwartą możliwość cichych awarii.
Wygląda na to, że w twoim przypadku wystarczy zwykłe potwierdzenie z retransmisją po upływie czasu bez otrzymania potwierdzenia.
Zrobiłem wiadomości XML przez utrzymywane połączenie TCP i działało świetnie. Miałem warstwę, która dostarczała kompletne komunikaty w buforze do warstwy aplikacji do obsługi. Użyłem XML, aby spakować wiadomość znacznikiem początkowym XML na początku wiadomości i znacznikiem końcowym XML, aby wiedzieć, kiedy cała wiadomość została odebrana.
TCP ma kilka funkcji, takich jak sekwencyjna kolejność pakietów, brak powtórzeń, a bycie połączonym mechanizmem transportowym oznacza, że wiesz, czy drugi koniec znika, czy nie, ale znalezienie go może trochę potrwać. Łączenie i rozłączanie może powodować opóźnienia, ale nie jest uciążliwe w zwykłych warunkach, chociaż warunki sieciowe mogą powodować spowolnienie przepustowości TCP.
MQTT jest protokołem transportowanym przez warstwę transportu sieciowego, zwykle TCP. MQTT korzysta z modelu publikowania / subskrybowania, więc nie ma przechowywania wiadomości. Kiedy więc wydawca opublikuje wiadomość, jeśli subskrybent nie jest połączony w tym czasie, to kiedy się połączy, nie zobaczy wiadomości. MQTT działa w czasie rzeczywistym, przypuszczam, że o to właśnie chodzi w części telemetrycznej akronimu. Lubię MQTT dla małych wiadomości i przeprowadzam eksperymenty z ładunkiem JSON poprzez MQTT przy użyciu Mosquitto. Zobacz ten artykuł Niezawodne dostarczanie wiadomości za pomocą Mosquitto (MQTT) z przeglądem MQTT i jakości usług. I zobacz ten krótki artykuł z linkami do zasobów, w tym przykładowej aplikacji IoT - MQTT Publish and Subscriber C Code .
Moje eksperymenty z MQTT przy użyciu tekstu JSON i bazy danych SQLite3 u subskrybenta do przechowywania wiadomości znajdują się pod adresem https://github.com/RichardChambers/raspberrypi/tree/master/mqtt, chociaż źródło znajduje się w C i jest dość nieuporządkowane.
Oto 13-minutowy film # 144 Protokoły internetowe: CoAP vs MQTT, Network Sniffing i przygotowania do hakowania IKEA Tradfri . To ciekawy artykuł o CoAP, ograniczonym protokole aplikacji: CoAP to „nowoczesny” protokół IoT . Oto podsumowanie CoAP:
Wcześni użytkownicy zgadzają się, że protokół ograniczonego stosowania działa wyjątkowo dobrze w przypadku ograniczonych sieci i urządzeń. Coś nie tak dobrze znanego: „W bardzo przepełnionej sieci bezprzewodowej - Wi-Fi lub komórkowej - CoAP może nadal działać, gdy protokół oparty na protokole transmisji (TCP), taki jak MQTT, nie może nawet ukończyć uzgadniania, - powiedział Vermillard.
Wynika to z faktu, że w przeciwieństwie do większości innych protokołów IoT, CoAP jest oparty na UDP. Innymi słowy, oznacza to brak uzgadniania protokołu lub korekcję błędów, jakie występują w przypadku protokołu TCP. „CoAP może nie być tak niezawodny jak HTTP lub gwarantować dostarczanie wiadomości takich jak MQTT, ale jest niezwykle szybki” - zauważył Matthieu. „Jeśli nie masz pewności, że niektóre wiadomości nie zostały odebrane, możesz wysłać o wiele więcej wiadomości w tym samym czasie”.
Jest jeszcze kilka innych, takich jak AMQP, STOMP i CBOR, na które możesz również spojrzeć. Zobacz standardową stronę internetową CBOR, a także tę tezę, Wdrażanie i ocena protokołu CBOR . Zobacz ten artykuł, Wybór protokołu przesyłania wiadomości: AMQP, MQTT lub STOMP, który porównuje i kontrastuje AMQP, MQTT i STOMP i kończy się notatką o brokerze RabitMQ:
Mamy nadzieję, że może to pomóc wielu osobom rozpocząć nawigację po protokole zupy dla każdego z przypadków użycia. Ponieważ firmy mają wiele aplikacji o różnych potrzebach, z pewnością możliwe jest, że będziesz potrzebować wszystkich trzech brokerów w różnych aplikacjach. W tym momencie pojawia się solidny wieloprotokolowy broker polyglot, taki jak RabbitMQ - ponieważ może wysyłać STOMP, MQTT lub AMQP i wydobywać jednego z pozostałych. Jeden z tych protokołów nie musi być zablokowany - wszystkie trzy są obsługiwane przez brokera RabbitMQ, co czyni go idealnym wyborem dla interoperacyjności między aplikacjami. Architektura wtyczek umożliwia również RabbitMQ ewolucję w celu obsługi dodatkowych lub zaktualizowanych wersji tych protokołów w przyszłości.
Ten pakiet udostępniania slajdów z około 60 slajdów porównuje i kontrastuje cztery różne protokoły IoT, uwzględniając potrzeby dwóch różnych grup IoT, Konsumentów i Przemysłu, które mają różne potrzeby w zakresie niezawodności i solidności. Jaki jest właściwy standard przesyłania wiadomości dla IoT? .
Acking nie jest konieczne. Myślę, że praca nad niezawodnością na UDP nie ma większego sensu, po to właśnie jest TCP.