Czy powinienem używać gniazd sieciowych Mosquitto, czy bezpośrednio łączyć klientów?

11

Według tego bloga Mosquitto (broker MQTT) obsługuje teraz łączenie się z klientami przez gniazda sieciowe. Artykuł na blogu wydaje się sugerować, że gniazda sieciowe są bardziej przydatne dla aplikacji przeglądarkowych, ponieważ przeglądarki internetowe nie obsługują jeszcze odpowiednich gniazd TCP (chociaż), chociaż protokół gniazd sieciowych jest obsługiwany przez większość współczesnych przeglądarek.

Jeśli mam po prostu różnych klientów w sieci (np. Czujniki i urządzenia wykonawcze oparte na mikrokontrolerach, takich jak Raspberry Pis), czy korzystanie z gniazd sieciowych w porównaniu z bezpośrednimi połączeniami TCP przyniesie jakieś korzyści? Czy narzut związany z protokołem gniazd sieciowych jest tego wart tylko podczas komunikacji z przeglądarką?

mqtt mosquitto web-sockets

— Aurora0001
źródło

1

Czy możesz nam powiedzieć, czy kodujesz całą sieć? Czy to wszystkie węzły, czy klient i serwer? A jeśli musisz wchodzić w interakcje z czyimś oprogramowaniem? Wygląda na to, że

— kodujesz

1

@Mawg serwer będzie brokerem Mosquitto MQTT, ale mogę wybrać protokół, którego używam dla wszystkich klientów (i Mosquitto oferuje zarówno gniazda sieciowe, jak i bezpośrednie połączenia TCP, dlatego zapytałem).

— Aurora0001

1

Myślę, że jest tu trochę zamieszania. Zakładam, że @ Auroa0001 oznacza „bezpośredni TCP”, używając MQTT przez TCP, a nie MQTT przez Websockets (... przez TCP). W obu przypadkach dostępne są biblioteki, więc nie trzeba pisać kodu dla gniazd.

— ralight

@ prawo tak, to był mój zamiar naprawdę podczas zadawania pytania. Wygląda na to, że odpowiedzi poszły trochę w błąd.

— Aurora0001

7

Wydaje się, że pytanie brzmi „czy powinienem używać MQTT przez TCP, czy używać MQTT przez websockets (które również przechodzą przez TCP)?” Innymi słowy, czy „enkapsulacja MQTT w protokole websockets jest dobrym pomysłem?”

Jest to (prawie) całkowicie zależne od twojej aplikacji i tego, czy potrzebujesz obsługi gniazd sieciowych - prawdopodobnie do konsumpcji wiadomości w przeglądarce lub ze względów zapory ogniowej. Jeśli nie możesz mieć dostępu do twojego serwera na porcie 1883 lub lepszym 8883 dla czystego MQTT, wtedy websockets mogą być najlepszą opcją.

Websockets wymaga dodatkowej przepustowości, ale to, co jest dla Ciebie ważne, jest czymś, na co tylko możesz odpowiedzieć.

Warto również zauważyć, że w obecnych wersjach Mosquitto websockets nie działają tak dobrze, jak mogłyby, więc może wystąpić dodatkowe opóźnienie podczas wysyłania / odbierania wiadomości websockets. Nie będzie to jednak problemem w przyszłych wersjach.

— ralight
źródło

7

Podczas komunikowania się tylko wewnątrz swojej sieci ( intranet ), przy użyciu czystego TCP będzie dobrze. Ale jeśli będziesz musiał połączyć się z innym serwerem, pojawią się problemy.

Ponieważ większość współczesnych serwerów nie pozwala klientom łączyć się przez losowe porty. Umożliwiają połączenie tylko niektórych dedykowanych portów. To wszystko. Dlatego jeśli musisz połączyć się z innym serwerem, lepiej użyć websocket niż czystego połączenia TCP.

Jeśli bierzesz pod uwagę koszty ogólne, nie jest to aż tak dużo większe. Możesz odnieść się do tego artykułu , jeśli chcesz dowiedzieć się więcej na temat narzutów websocket.

Moim osobistym zdaniem lepiej jest zawsze korzystać z websocket, chyba że masz poważne obawy.

— ThisaruG
źródło

2

Err, TCP i websockets to protokoły: tools.ietf.org/html/rfc6455 , ponadto TCP IS jest gniazdem na niskim poziomie.

— Goufalite,

@ThisaruGuruge dzięki za odpowiedź - w moim scenariuszu w pytaniu zakładam, że wybrałbyś TCP zamiast gniazd sieciowych, sądząc po twojej odpowiedzi? Zwłaszcza, że gniazda sieciowe wydają się być obsługiwane głównie przez przeglądarki, więc narzucenie kodu wymaga użycia gniazd sieciowych przez gniazda TCP.

— Aurora0001

1

„większość współczesnych serwerów nie pozwala klientom łączyć się przez losowe porty” - serwer może wybrać port, z którym ma się połączyć ( man7.org/linux/man-pages/man2/bind.2.html ), a dodatkowo zapora może dalej to ograniczaj. JEDNAK nie zgadzam się, kiedy mówisz „jeśli musisz połączyć się z innym serwerem, pojawią się problemy ”. Przeformułuj to jako „ może powstać”. Nawet wtedy jest to kwestia konfiguracji, które gniazda sieciowe prawdopodobnie będą łatwiejsze niż gniazda zwykłe.

— Mawg mówi o przywróceniu Moniki

6

tl; dr - zawsze wolę darmowe biblioteki od kodowania go samodzielnie (chyba że masz ekstremalne wymagania)

Czy powinienem używać gniazd sieciowych Mosquitto, czy bezpośrednio łączyć klientów?

Jak długi jest kawałek sznurka? (YMMV)

Mogę mówić tylko ogólnie, ale zawsze wolę biblioteki opakowań od surowych gniazd (a nawet kodowania wszystkiego, co mogę dostać za darmo z biblioteki).

Ułatwiają kodowanie i są mniej podatne na błędy. Zajmują się wieloma czynnościami związanymi z utrzymywaniem domu i obsługą błędów, czyli kodem, który sam musiałbyś napisać i debugować, podczas gdy biblioteka jest ogólnie dobrze sprawdzona i przetestowana i jest używana przez tysiące innych osób, z których wszystkie są używane zgłosi / naprawi za ciebie błędy.

Co więcej, jest mniej kodu do utrzymania (i ewentualnie portu), co oznacza więcej czasu na opracowanie, przetestowanie i dopracowanie aplikacji lub przejście do następnej.

Jedynym narzutem jest prawdopodobnie wywołanie funkcji, jeśli zaakceptujesz, że cała ta dobroć bibliotekarza (obsługa błędów, utrzymywanie węża i tym podobne) jest czymś, co musiałbyś sam kodować, aby uzyskać dobre, stabilne oprogramowanie.

Jeśli obawiasz się o wydajność, po prostu profil. Ale jeśli twoje gniazdo nie jest aktywne setki razy na sekundę, nawet nie zawracałbym sobie głowy.

— Mawg mówi, że przywróć Monikę
źródło

Cóż, istnieją bezpłatne biblioteki dla połączeń TCP i połączeń (internetowych) z gniazdami, i oba wymagają zdarzenia „odebrany komunikat”.

— Goufalite,

2

OP chce wiedzieć, czy lepiej jest używać TCP lub gniazd sieciowych dla zwiększenia wydajności , a ty mówisz „użyj biblioteki abstrakcji, żebyś nie zawracał sobie głowy”. Jasne, ale który? W języku C # w System.Net.Sockets znajduje się biblioteka TcpClient (cóż, cóż ...) oraz biblioteka websocket w pakiecie nuget (WebSocketSharp). Zgadzam się, że istnieje ogólna biblioteka MQTT dla wszystkich języków, ale OP chce mieć nad nią kontrolę, aby wybrać protokół, którego ma używać.

— Goufalite,