Лекція 2.2. Передача даних в архітектурі IIoT: MQTT
6. Обмін повідомленнями в MQTT
6.1. Процедура з’єднання
https://www.hivemq.com/blog/mqtt-essentials-part-3-client-broker-connection-establishment/
З'єднання з використанням MQTT починається з того, що клієнт відправляє повідомлення CONNECT брокеру. Тільки клієнт може ініціювати сеанс, і жоден клієнт не може безпосередньо зв'язатися з іншим клієнтом. У відповідь на повідомлення CONNECT брокер завжди буде відсилати CONNACK і код статусу. Після встановлення з'єднання, воно починає працювати.
У табл.1 наведені дані для з’єднання п процедурі CONNECT MQTT.
|
Поле |
Обов’язкове поле |
Опис |
|
clientID |
Так |
Ідентифікує клієнта не сервері. Кожний клієнт має унікальний ідентифікатор, від 1 до 23 байт UTF-8. |
|
cleanSession |
Ні |
0: сервер повинен відновити зв'язок з клієнтом. клієнт і сервер повинні зберегти стан сеансу після відключення; 1: клієнт і сервер повинні відмінити попередній сеанс і почати новий |
|
username |
Ні |
Ім’я, що використовується сервером для автентифікації |
|
password |
Ні |
пароль |
|
lastWillTopic |
Ні |
тема (topic) гілки для публікації повідомлення «останньої волі» |
|
lastWillQos |
Ні |
рівень QoS (0..2) повідомлення «останньої волі» |
|
lastWillMessage |
Ні |
Корисне навантаження (payload) повідомлення «останньої волі» |
|
lastWillRetain |
Ні |
Чи зберігається повідомлення «останньої волі» після публікації |
|
keepAlive |
Ні |
Інтервал часу в секундах keep-alive (утримування) |
При відповіді CONNACK, сервер (брокер) буде повертати код відповіді, які наведені в таблиці 2.
|
Код відповіді |
Опис |
|
0 |
Успішне з’єднання |
|
1 |
У з’єднанні відмовлено : неприйнятна версія протоколу MQTT |
|
2 |
У з’єднанні відмовлено : ідентифікатор клієнта – це правильний UTF-8, однак не дозволений сервером |
|
3 |
У з’єднанні відмовлено : сервер не досяжний |
|
4 |
У з’єднанні відмовлено : невірне ім’я користувача чи пароль |
|
5 |
У з’єднанні відмовлено : клієнт не авторизований для з’єднання |