Jaka jest różnica między MQTT a gniazdami internetowymi i kiedy powinienem ich używać?

Jakie są główne różnice między MQTT a gniazdami internetowymi?

Korzystając z IoT do automatyzacji domu - kontroluj i monitoruj dostęp na różnych urządzeniach, z których jedno powinno być używane, gdy wymagana jest dostępność interfejsu Rest API i przeglądarka.

Korzystam z Java (Pi4J Library) na Raspberry Pi 2 B +.

Mam zestaw kilku czujników, takich jak światło i ciemność, wilgotność, PID itp.

Mam również serwer w chmurze, na którym mogę przesyłać dane w razie potrzeby.

communication monitoring mqtt

— Shakti Phartiyal
źródło

Ty decydujesz, którego użyć, jasno określając wszystkie obecne i prawdopodobne przyszłe wymagania. Następnie generujesz macierz krzyżową pokazującą, która technologia najlepiej spełnia Twoje wymagania. Następnie wybierz jedną lub więcej technologii, aby spełnić Twoje wymagania.

Odpowiedzi:

Przedstawione tutaj pytanie jest nieco mylące, ponieważ w rzeczywistości tych protokołów w ogóle nie można porównywać razem. Są jak TCP i IP, warstwy nad sobą. [1]

Websockets to protokół niskiego poziomu, który zapewnia rzeczy, których nie zapewnia jego „konkurencyjny” RESTful http, który jest na tym samym poziomie: zawsze otwarty kanał bez potrzeby otwierania i zamykania na każde żądanie. [2]

MQTT zapewnia lekki sposób publikowania lub subskrybowania danych. Problemem może być to, że te subskrypcje są jakimś kanałem, ale jest to inny typ kanału. Aby uzyskać stałe otwarte połączenie w MQTT, potrzebujesz Websockets ORAZ MQTT w tym samym czasie.

W IoT, a także w dowolnym projekcie, musisz wybrać, czy potrzebujesz strumienia, czy nie (WebSockets vs. RESTful), a jeśli chodzi o MQTT, możesz pomyśleć, czy chcesz mieć subskrypcję i mechanizm publikowania w swojej aplikacji.

W niektórych okolicznościach możesz rozważyć użycie MQTT przez WebSockets, jeśli jest coś wspólnego. [3]

Odpowiedz na pytanie:

Mówisz, że masz konfigurację Rasperry Pi i kilka czujników w tym miejscu. Jeśli czujniki są dalekie od Rasperry z własnymi kontrolerami, możesz użyć MQTT do zbierania danych. Aby przechowywać dane w chmurze, wyślij dane w HTTP. W chmurze dostarczaj dane przez resztę. [4]

W przypadku gniazd sieciowych nie ma takiej potrzeby, ale jeśli uznasz to za przydatne, zrób to.

Źródła:

[1] https://www.quora.com/What-are-the-pros-and-cons-of-WebSockets-versus-MQTT-as-real-time-web-infrastructure-for-the-Internet-of -Rzeczy

[2] https://www.pubnub.com/blog/2015-01-05-websockets-vs-rest-api-understanding-the-difference/

[3] /programming/30624897/direct-mqtt-vs-mqtt-over-websocket

[4] http://www.theinternetofthings.eu/antonio-grasso-mqtt-vs-http-what-best-protocol-iot

— mico
źródło

Istotny również dla twojego ostatniego punktu: Ta odpowiedź autorstwa Rogera Lighta, twórcy brokera Mosquitto MQTT, porównująca przypadki użycia gniazd surowych z gniazdami sieciowymi z MQTT.

— Aurora0001

Dziękuję mico, to wspaniałe wyjaśnienie. ale nadal nie jestem pewien, czego użyć ... co poleciłbyś w moim scenariuszu?

— Shakti Phartiyal

Świetna odpowiedź, ale: użycie „otwórz i zamknij” WRT WS: // vs. HTTP: // może wprowadzać w błąd; po pierwsze, żądania HTTP 1.1 mogą być przetwarzane potokowo, więc na poziomie gniazd dosłownych jedno połączenie może zawierać nieokreśloną liczbę żądań bez otwierania i zamykania w tym sensie. Lepiej byłoby powiedzieć, że zaletą websockets jest brak zaangażowania w synchroniczny cykl „żądanie i odpowiedź” ; masz otwarty, dwukierunkowy kanał z minimalnym zestawem zasad wymiany.

— złotowłosa

„Aby uzyskać stałe otwarte połączenie w MQTT, potrzebujesz Websockets ORAZ MQTT w tym samym czasie.” Jesteś tego pewien? Wyjaśnij, dlaczego MQTT musi używać webSockets, aby utrzymać „stałe otwarte połączenie”, jeśli klient może po prostu kontynuować publikowanie pakietów PINGRESP z powrotem na serwer? Klient implementujący MQTT wyśle pakiet PINGRESP, aby utrzymać połączenie przy życiu, a klient wcielający się w webSockets użyje keepAlive () do wysłania pustego pakietu webSocket.send ('') na serwer, aby utrzymać połączenie przy życiu.

— John

Hmm .. Możesz utrzymać połączenie z tym pakietem . Dowiedziałem się, że MQTT działa przez TCP / IP (nie HTTP). W takim przypadku możesz pozostawić połączenie otwarte.

— mico

Są one porównywalne, ponieważ oba umożliwiają komunikację w trybie pełnego dupleksu, dzięki czemu serwer może natychmiast przesłać dane do klienta, bez odpytywania go przez klienta (jak w przypadku HTTP).

Jednak Websockets jest przeznaczony do prostego połączenia punkt-punkt między klientem a serwerem. MQTT nakłada dodatkowe abstrakty na podstawowe wysyłanie wiadomości, dzięki czemu wiele zainteresowanych stron może subskrybować wiadomości, które mogą ich zainteresować. Wiadomości mogą być zatem kierowane według „tematu wiadomości”, dzięki czemu wielu klientów może współużytkować hipotetyczną kolejkę, w której serwer może wybrać odsłuchiwanie wszystkich wiadomości od wszystkich klientów, ale może także filtrować według tematu.

MQTT ma wiele innych przydatnych funkcji, np. Zachowane wiadomości, dzięki czemu subskrybenci natychmiast otrzymują wiadomość, oraz LWT (Last Will and Testament), który jest wiadomością, która może zostać wysłana automatycznie, jeśli klient nieprawidłowo się rozłączy. Podsumowując, MQTT jest „wyżej w stosie”, oferując funkcje i abstrakcje, których nie ma zwykły Websocket.

— TheMagicCow
źródło