Чи варто використовувати веб-розетки Mosquitto або безпосередньо підключати клієнтів?


11

Відповідно до цього блогу , Mosquitto (брокер MQTT) тепер підтримує підключення до клієнтів через веб-сокети. У блозі стаття , здається, натякають , що веб - сокети є більш корисними для браузерних додатків, так як веб - браузери не підтримують відповідні сокети TCP (поки), хоча протокол веб - сокет буде підтриманий більшістю сучасних браузерів.

Якщо у мене просто є різні клієнти в мережі (наприклад, датчики та пускачі на основі мікроконтролерів, таких як Raspberry Pis), чи буде якась перевага від використання веб-розеток над прямими TCP-підключеннями? Чи варто накладати накладні витрати на протокол веб-сокета лише під час спілкування з браузером?


1
Скажіть, будь ласка, чи кодуєте всю мережу? Тобто всі вузли або клієнт і сервер? Або якщо вам доведеться взаємодіяти з чужим програмним забезпеченням? Здається, що ви можете кодувати лише клієнтів, але я не можу бути впевнений
Мауг каже, що поверніть Моніку

1
@Mawg сервер буде брокером Mosquitto MQTT, але я можу вибрати, який протокол я використовуватиму для всіх клієнтів (і Mosquitto пропонує як веб-розетки, так і прямі TCP-з'єднання, через що я запитав).
Aurora0001

1
Я думаю, тут є деяка плутанина. Я припускаю, що "Auroa0001" означає "прямий TCP" використовує MQTT через TCP, а не MQTT через Websockets (... через TCP). В обох випадках є бібліотеки, тому не потрібно писати код для сокетів.
ralight

@ralight так, це був мій намір справді, коли задавали питання. Відповіді справді трохи збилися, здається.
Aurora0001

Відповіді:


7

Питання тут виглядає так: "чи слід використовувати MQTT через TCP або використовувати MQTT через веб-розетки (що також переходить через TCP)?" Іншими словами, чи є "інкапсуляція MQTT у протоколі websockets хорошою ідеєю?"

Це (майже) повністю залежить від вашої програми та чи потрібна вам підтримка веб-розетки - ймовірно, для споживання повідомлень у веб-переглядачі чи з міркувань брандмауера. Якщо ви не можете зробити ваш сервер доступним на порт 1883 або краще 8883 для чистого MQTT, веб-розетки можуть бути найкращим варіантом.

Веб-розетки вимагають додаткової пропускної здатності, але чи важливо для вас це лише те, що ви можете відповісти.

Варто також відзначити, що в сучасних версіях Mosquitto веб-розетки працюють не так добре, як вони могли, тому можуть надходити додаткові затримки під час надсилання / отримання повідомлень веб-сокетів. Це те, що не буде проблемою у майбутніх версіях.


7

Коли ви спілкуєтеся лише всередині своєї мережі ( інтранет ), використання чистого TCP буде добре. Але якщо вам доведеться підключитися до іншого сервера, виникнуть проблеми.

Тому що більшість сучасних серверів не дозволяють клієнтам підключатися через випадкові порти. Вони дозволяють підключитися лише до деяких виділених портів. Це все. Отже, якщо вам доведеться підключитися до іншого сервера, краще використовувати websocket, а не чисто TCP-з'єднання.

Якщо ви розглядаєте накладні витрати, це не Набагато більше. Ви можете посилатися на цю статтю , якщо хочете дізнатися більше про накладні витрати веб-розетки.

На мою особисту думку, краще використовувати веб-розетку завжди, за винятком серйозних проблем.


2
Err, TCP та websockets - це протоколи: tools.ietf.org/html/rfc6455 , крім того, TCP IS сокет на низькому рівні.
Гуфаліт

@ThisaruGuruge дякую за вашу відповідь - в моєму сценарії у питанні я припускаю, що ви вибрали TCP через веб-розетки, судячи з вашої відповіді? Тим більше, що, здається, веб-розетки підтримуються в основному браузерами, тому існує надмірний код необхідності використання веб-розеток через сокети TCP.
Aurora0001

1
"більшість сучасних серверів не дозволяють клієнтам підключатися через випадкові порти" - сервер може вибрати, до якого порту підключатись ( man7.org/linux/man-pages/man2/bind.2.html ), а також брандмауер може ще більше обмежити це. ОДНАК, я НЕ згоден , коли ви говорите «якщо у вас є , щоб підключитися до іншого сервера, проблеми будуть виникати». Перефразовуйте це як " може виникнути". Вже тоді, справа в конфігурації, які веб-розетки, ймовірно, будуть простішими, ніж необроблені сокети.
Мауг каже, що повернемо Моніку

6

tl; dr - завжди віддайте перевагу безкоштовним бібліотекам, щоб кодувати його "(якщо ви не маєте екстремальних вимог)"


Чи варто використовувати веб-розетки Mosquitto або безпосередньо підключати клієнтів?

Як довгий шматок струни? (YMMV)

Я можу говорити лише загалом, але завжди віддаю перевагу бібліотекам обгортки перед необробленими сокетами (або, справді, кодуванням всього, що я можу отримати безкоштовно з бібліотеки).

Вони роблять кодування простішим і менш схильним до помилок. Вони піклуються про багато ведення домашнього господарства та керування помилками, що є кодом, який вам доведеться писати і налагоджувати самостійно, де бібліотека, як правило, добре перевірена і перевірена і використовується тисячами інших, всі з яких повідомить / виправить помилки для вас.

Плюс - це менше коду для підтримання (і, можливо, порту), що означає більше часу на розробку, тестування та полірування додатка або перехід до наступного.

Єдиний накладні витрати - це, можливо, виклик функцій, якщо ви погоджуєтесь, що все те, що користь бібліотекаря (обробка помилок, утримання шлангів тощо) - це те, що вам доведеться кодувати собі, щоб отримати гарне, стабільне програмне забезпечення.

Якщо вас турбує ефективність, просто профілі. Але, якби ваша розетка не була активною сотні разів в секунду, я б навіть не турбувався.


Ну, є безкоштовні бібліотеки для TCP-з'єднань та (веб) підключень сокетів, і для обох потрібна подія "отримане повідомлення".
Гуфаліт

2
ОП хоче знати, чи краще використовувати TCP або веб-розетки для ефективності , і ви говорите "використовуйте бібліотеку абстракцій, щоб ви не турбувались". Звичайно, але який? В C # Є бібліотека TcpClient в System.Net.Sockets (ну, добре ...) і бібліотека веб-сокетів в нут-пакет (WebSocketSharp). Я погоджуюся, що існує загальна бібліотека MQTT для всіх мов, але ОП хоче мати контроль над нею, щоб вибрати, який протокол він повинен використовувати.
Гуфаліт
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.