MQTT jako protokół komunikacyjny w prostym komunikatorze

Question

Cześć!

Chcę zrobić prosty program służący do komunikacji tekstowej i zastanawiam się nad wyborem protokołu, który służyłby do komunikacji klientowi otrzymania nowej wiadomości (ale też np. otrzymania zaproszenia do znajomych).

Obecnie jako wybór rozpatruję wybór MQTT, ale nie jestem pewny co do wyboru tego protokołu, jako że jest to odrobinę nietypowe wykorzystanie.

Przykładowy schemat komunikacji przedstawiałby się następująco:

1. Klient pobiera klucz publiczny z api.
2. Klient komunikuje sie z rest api - loguje sie za pomoca username i password (szyfrowane z wykorzystaniem pobranego klucza publicznego).
3. Serwer zwraca jwt tokena, tokena do odswiezania tego pierwszego i jwt tokena jako device cookie (o ile zaznaczono remember me).
4. Klient subskrybuje topicki, np. jwttoken:messages lub jwttoken:conversationid.
5. Klient wysyła obiekt wiadomości - do rest api, które zapisuje ją w bazie danych i publishuje (wykorzystując brokera np. mosquitto)  nową wiadomość (obiekt klasy zdeserializowany do jsona) do topicka właściwego dla docelowego odbiorcy.
6. Odbiorca subskrybujacy topic odbiera wiadomość i deserializuje obiekt.

W związku z tym chciałbym się zapytać, czy ktoś może miał styczność z takim wykorzystaniem i czy istnieje sens takiego rozwiązania (a jak nie w jakim kierunku mógłbym się skierować - oprócz okresowego odpytywania api, czy nie pojawiło się coś nowego)?

Comments

Z tego co wiem to przeglądarki nie obsługują MQTT. Są nakładki, które używają WebSocket pod spodem. Dlatego według mnie nie ma sensu używać MQTT w komunikatorach czy w innych aplikacjach czasu rzeczywistego. Mogą to robić duże korporacje, które mają odpowiedni budżet i programistów(jak Facebook), a tak to sobie tylko utrudnisz  życie.

---

Akurat nigdzie nie wspomniałem, że będę przygotowywał przeglądarkowego klienta. Będzie to natywna aplikacja (prawdopodobnie na androida i windowsa). Zresztą akurat jest sporo gotowych przykładów dla przeglądarek (z użyciem websocketów), np. http://www.hivemq.com/demos/websocket-client/

Więc w razie rozbudowy nie powinno być problemu ze stworzeniem tego typu klienta (chociaż do tego zapewne nie dojdzie, nie chciałbym niczyich oczu skalać moim poziomem JS).

Kwestia więc, czy takie rozwiązanie ma jakikolwiek sens, w porównaniu do WebSocketów (z którymi, w odróżnieniu do MQTT, nigdy nie miałem styczności).

---

Nigdy nie mów nigdy  Dużo zależy od tego jak twoja technologia, którą wybrałeś wspiera MQTT czy WebSocket. Obie drogi są dobre i z tego co testowałem to pod względem wydajności są w praktyce podobne. WebSocket jak i MQTT wysyłają kontrolne wiadomości(przeważnie co 30 sekund) i zużycie danych jest trochę mniejsze dla MQTT, ale w praktyce to bez znaczenia. Więc lepiej w tym przypadku wybrać technologię którą się lepiej zna :)

---

Należy zacząć od tego, że to kompletnie dwie różne "technologie", których nie należy porównywać. Chyba, że brakuje Ci wiedzy, to śmiało... Służą kompletnie do czego innego. Naturalnym wyborem przy komunikatorze jest websocket, chyba, że chcesz spróbować czegoś innego. 

MQTT wysyłają kontrolne wiadomości(przeważnie co 30 sekund)

To nie jest prawda. Przeważnie, to zależy od implementacji, bo standard tego nie stwierdza. Stwierdza, że taka możliwość jest i nazywa się "Keep Alive". 

 

---

Z tego co widziałem to praktycznie większość używa 30sekund jako domyślnej wartości, które przeważnie można zmienić. Obie technologie są podobne w użyciu i na obu można zrobić dokładnie to samo - na wyższym czy niższym poziomie.

---

Teoretycznie i teslą, i starą ładą dojedziesz z punktu A do B. Kwestia, czy należy to porównywać. MQTT i Websockety różnią się diametralnie. Zważywszy, że zostały stworzone do z grubsza innych rzeczy.

Pythonowa implementacja używa 60 sekund. Jeszcze, co do pierwszego Twojego komentarza. Przeglądarki obsługują MQTT. Bo obsługują websockety, a oba protokoły są na TCP.

---

Przeglądarki obsługują MQTT. Bo obsługują websockety, a oba protokoły są na TCP

Wow naprawdę? Ale ta technologia się szybko zmienia. Rok temu z tego co wyczytałem nie było takiej możliwości. Opierałem się na tym wpisie na: https://stackoverflow.com/questions/16047344/can-a-web-browser-use-mqtt

Tylko ty traktujesz to bardziej teoretyczne. Owszem WebSocket i MQTT w teorii mocno się różnią. Dlatego używam słowa "technologia", a nie protokół. Nie samym protokołem człowiek żyje. 

Tak samo WebSocket można zastąpić samym HTTP, albo HTTP long polling. Ktoś na SO pisał, że są to dwie różne rzeczy(HTTP i WebSocket)- tak są, ale da się osiągnąć dokładnie to samo. Np. biblioteka SignalR używa jako alternatywy WS właśnie HTTP i HTTP long polling. Więc zamiast myśleć nad teorią i standardem, warto myśleć co można osiągnąć za pomocą konkretnej technologii i jakie są wady i zalety jej implementacji w projekcie.

---

Wow naprawdę? Ale ta technologia się szybko zmienia. Rok temu z tego co wyczytałem nie było takiej możliwości. Opierałem się na tym wpisie na: https://stackoverflow.com/questions/16047344/can-a-web-browser-use-mqtt

Oba protokoły są oparte na TCP. Więc w czym problem? 

Tylko ty traktujesz to bardziej teoretyczne. Owszem WebSocket i MQTT w teorii mocno się różnią. Dlatego używam słowa "technologia", a nie protokół. Nie samym protokołem człowiek żyje. 

Nie tylko w teorii... Co do ostatniego zdania. Zależy jak nisko schodzisz. 

Imo od tego jest standard, by wyciągać wnioski gdzie najlepiej się to sprawdzi. 

 

---

Oba protokoły są oparte na TCP. Więc w czym problem? 

Skąd mam to wiedzieć? Nie tworzę przeglądarek. Żadna przeglądarka nie wspierała w 2020 roku bezpośrednio MQTT.