MQTT
誤った情報もあるかと思います。
訂正やFB大歓迎ですので、よろしくお願いします。
MQTTとは
MQTT(Message Queueing Telemetry Transport)はPub/Sub型のシンプルで軽量なプロトコルです。
M2MやIoTに適していると言われており、私が考える理由は以下の点です。
- 多数のデバイスで短いメッセージのやりとりを想定して作られている
- 1:多での情報のやりとりができる(MQTTというよりかはPub/Subの恩恵)
- 非同期で双方向通信である
- 軽量のため消費電力が少ない
多数のデバイスで短いメッセージのやりとりを想定して作られている
MQTTはPub/Sub型のシンプルで軽量なメッセージングプロトコルです。
制約のあるデバイスや、低帯域幅、または信頼性の低いネットワーク向けて設計されている点からIoTやM2Mと相性が良いです。
1:多での情報のやりとりができる
これはMQTTというよりかは、Pub/Subの恩恵かなと思っています。(非同期通信も)
製造IoTでいえば、センサーなどIoTデバイスとのやりとりは何千台となることも考えられます。
そういった世界で1:1でのやりとりは非効率ですので、1:多もしくは多：多が可能なMQTTはうれしいですね。
非同期で双方向通信である
非同期通信とは送信側と受信側を空間・時間から切り離されているイメージです。
逆にHTTPのような同期通信をイメージすると、クライアントがサーバーからのレスポンスを待機します。
IoTなどはデバイスが多いため、それぞれと同期通信をするのは時間がかかりすぎて問題になります。
また、同期通信はネットワークが不安定もしくはサーバーが故障した場合はやりとりができません。
非同期通信は、ネットワークが死んだ場合や、サーバーが故障した場合に復旧と同時にデータを再送信することができます。
IoTでは、想定されるケースが多いためネットワークの信頼性が低い場合もあります。
そういった時でも非同期は役に立ちます。
軽量のため消費電力が少ない
ヘッダのサイズです。
- HTTPヘッダ：50バイト～
- MQTTヘッダ：2バイト～
ここからMQTTプロトコルは極めて軽量だということがわかるかと思います。
実際には256MBが最大メッセージサイズであり、これだけ入れることはあまり想定されていないと思います。
ネットでは256MBだったら・・・そんな変わらないんじゃという話はありますがここでは無視します。
やっぱりIoTのような環境によって条件が変わる場合にネットワークの帯域が限られている場合もあり、HTTPヘッダでは適していません。
また軽量ということは処理も軽く消費電力です。
電源が供給できないような場合はバッテリーが使われますが、消費電力が少ない方がよいので助かります。
MQTTの資料
自分はこの辺りを見て学びました。
よければ参考にしてみてください。
MQTTのPub/Subとは何か？
MQTT(Message Queueing Telemetry Transport)はPub/Sub型のシンプルで軽量なプロトコルです。
Pub/Sub型とは一体なんでしょうか？
簡単に言ってしまえば、Publisher(送信側)からブローカーを通して、Subscriber(受信側)へメッセージを送ってあげています。
ブローカーを通すことで、PublisherとSubscriberが密になることはありません。
要するにpublisherはメッセージをsubscriberが受け取ったか気にせず送ります。
そもそもsuscriberがいるかも気にしていません。
逆にsubscriber側もメッセージを受け取った際にpublisherのことは知りません。
Topicでメッセージを振り分ける
これだと興味のないメッセージもpublisherから送られたら、subscliberは受け取ってしまいます。
ですので、すべてのメッセージにはtopicというラベルを付けます。
subscliberはブローカーに対して、トピックフィルタを作成してsubscribeをします。(定期購読)
topicはファイルシステム内のフォルダやファイルのような階層構造になっていて、スラッシュ（/）を区切り文字としてしようします。
※黄色は[/tsuda/hoge]というトピックスです。
QoS(Quality of Service)
メッセージをやりとりするうえでQoS(Quality of Service)サービスの品質が大切になります。
実際には、メッセージが届いたかどのレベルで保証するか設定するのがQoSです。
そのため送信側と受信側で品質レベルを0,1,2で決めます。
ここで送信側と受信側とあえて言っているのは、図のようにbrokerが送信でもあり受信でもあるためです。
QoS0
QoS0はとりあえず一回データを送信します。
が、それが受信側に届いたかどうかは確認しません。
QoS1
最低でも一回は届けることを保証しています。
メッセージを送信して、受信側からPUBACK(受取)が来ることで届いたことを確認します。
しかしQoS1は重複をすることがあります。
メッセージを送信して受信側からなんかしらの影響でPUBACK(受取)が来なかった場合、送信側が再送信するためです。
なぜ重複するのか・・・それは、
受信側は、このメッセージが再送or新規を把握できないから受け取ることしかできません。
重複しないためにはQoS2を使います。
QoS2
必ず届けることを保証し、重複もありません。
しかし、通信回数も増えるため一番負荷がかかります。
QoSのレベルを上げるほど、MQTTプロトコルのやりとりが多くなるのでオーバヘッドが大きくなります。
QoS2が重複しないのは、受信側がメッセージを受け取りPUBRECを送った時何かしらの理由で、送信側に届かなかった場合、
想定する次はPUBRELです。
ですが、メッセージが来た場合は、あれメッセージが再送信されたぞ？と把握できるためですね。
QoSの補足
ちなみに送信側と受信側でのQoSレベルはメッセージ発行者以上のQoSレベルを受信側は設定することはできません。
つまりメッセージ発行でQoS0を設定した場合は、QoS1,2は設定できないということです。
逆にメッセージ発行者がQoS2を設定した場合は、受信側でQoS0,1も設定できます。
そして、MQTTはそもそもTCPネットワークプロトコル上で実装されます。
TCPを使っているなら、データは届けられるよね？という疑問はありましたが、メッセージが届いたことは保証できません。
なぜなら、ネットワークトラブルでコネクションが切断したり、相手の電源が落ちた場合はメッセージが届いたかわからないためです。
TCPを使っていればつながっていることは保証していますが、メッセージが届いたかは保証できないのでQoSを利用します。
MQTTプロトコルの補足
MQTT(Message Queueing Telemetry Transport)は、Message Queueingと書かれているようにキューを使用されているかと思いきや、使われておりません。
キューが使われていないので、メッセージの順序を保証してくれません。
例えば、メッセージ送信でQoS2で発行しトランザクション中に、QoS0で発行した場合は逆になる可能性もあります。
順序を保証したい場合は、基本的には同じQoSレベルを使うもしくは順序保障している？QoS2を使うとよいかと思います。
デバイスの環境
| 仕様機器 | OS |
|---|---|
| Windows | Windows Home 11 |
| ラズパイ | ラズパイOS |
準備
Mosquittoをインストール
Mosquittoをインストールします。
私の場合は64ビットですので、こちらをインストールしました。
mosquitto-2.0.15-install-windows-x64.exe
OpenSSLが必要なためそれもインストールします。
OpenSSL
OpenSSLをインストールします。
2022/08/25時点ではWin64 OpenSSL v3.0.5 Lightが最新なのでこちらもインストールしてます。
OpenSSLを使ってアプリやサービスをしない限り軽量版でいいと思います。
※今回くらいであれば十分でした。
最後に寄付をするかと聞かれますので、私のようにケチな人はすべて外してFinishしてください。
完了したらMosquittoのパスを通します。
パスの通し方がわからない方はググれば簡単に出てくるので調べてください。
Mosquittoをダウンロードしたパスを追加します。(C:\Program Files\mosquitto)←あくまでも私の場合です
これで準備完了！！
実行
ブローカーの立ち上げ
コマンドプロントを立ち上げて以下のコードを打ちます
とくに何も起きませんが、これでBrokerが立ち上がりました。
ちなみにコマンドのオプションについては書きません。
公式マニュアルをご覧ください。
C:\Users\****> mosquitto
Subscribe側のクライアントを立ち上げる
立ち上げには以下のコードを新しいコマンドプロントで打ち込みます。
C:\Users\****> mosquitto_sub -d -t topicA
Client null sending CONNECT
Client null received CONNACK (0)
Client null sending SUBSCRIBE (Mid: 1, Topic: topicA, QoS: 0, Options: 0x00)
Client null received SUBACK
このコマンドは、クライアントを立ち上げてtopicAというトピックフィルタを作成してサブスクライブしました。
Client null sending SUBSCRIBE (Mid: 1, Topic: topicA, QoS: 0, Options: 0x00)
TopicはTopicAでQoSは0です。
QoSとは通信の品質で、0,1,2とありますが、0はただ送るだけです。
サブスクライブ側は受信ですので、送信側にちゃんと届いたといった応答はしないということです。
Publiah側のクライアントを立ち上げる
新しくコマンドプロントを開いて以下のコマンドを打つ
C:\Users\****>mosquitto_pub -d -t topicA -m "test"
Client null sending CONNECT
Client null received CONNACK (0)
Client null sending PUBLISH (d0, q0, r0, m1, 'topicA', ... (4 bytes))
Client null sending DISCONNECT
Client null sending PUBLISH (d0, q0, r0, m1, 'topicA', ... (4 bytes))が表示されていればOK
sub側のターミナルを確認すると・・・
Client null received PUBLISH (d0, q0, r0, m0, 'topicA', ... (4 bytes))
test
ちゃんとsub側でメッセージを取得できています。
ほかの機器と通信してみる
今回はラズベリーパイ zero Wを使ってみます。
ラズパイを使ってやってみたい方は、こちらを参考にMosquitto MQTT Brokerをインストールしてみてください。
ラズパイをBrokerにしてみる。
ラズパイにBrokerを立ち上げるので、IPアドレスを取得します。
pi@raspberrypi:~ $ hostname -I
192.168.*.*
以下のコマンドでBrokerを立ち上げます。
止めるときはstartをstopに変えてください。
pi@raspberrypi:~ $ sudo systemctl start mosquitto
特に何も起きませんが、これで立ち上がっています。
windowsでpub/subを作る
サブスクライブする
windowsでコマンドプロントを開いてラズパイに対してtopicAをサブスクライブします。
ポートは1883がデフォルトです。
C:\Users\****>mosquitto_sub -d -h 192.168.*.* -p 1883 -t topicA
Client null sending CONNECT
Client null received CONNACK (0)
Client null sending SUBSCRIBE (Mid: 1, Topic: topicA, QoS: 0, Options: 0x00)
Client null received SUBACK
Subscribed (mid: 1): 0
メッセージを送る
メッセージ送信もサブスクライブと同様にラズパイに向けて送ります。
C:\Users\****>mosquitto_pub -d -h 192.168.*.* -p 1883 -t topicA -m "test2"
Client null sending CONNECT
Client null received CONNACK (0)
Client null sending PUBLISH (d0, q0, r0, m1, 'topicA', ... (5 bytes))
Client null sending DISCONNECT
メッセージを受信
ちゃんと受け取ることができました。
今回は1:1でしたがもちろん、1:多もできますし、メッセージのtopicをtopicBとかにすれば受信しません。
色々試してみると面白いかと思います。
Client null received PUBLISH (d0, q0, r0, m0, 'topicA', ... (5 bytes))
test2