MQ Telemetry Transport
 |
MQ Telemetry Transport（Message Queuing Telemetry Transport、略称 MQTT）は、メッセージ指向ミドルウェアのアプリケーション層で使用される、TCP/IPによるPub/Sub型データ配信モデルの軽量なデータ配信プロトコルである。
MQTTのMQについて歴史的にはMQSeriesから来ているが、メッセージキューの機能は有していない。
非力なデバイスやネットワークが不安定な場所でも動作しやすいように、メッセージ通信電文が軽量に設計されていることが特徴である。
Pub/Sub型メッセージング·パターンには、メッセージブローカーが必要である。
ブローカーは、メッセージのTopicに基づいて、それを必要としているクライアントにメッセージを配信する。
アンディー·スタンフォード·クラークとシーラスリンクソリューションのアーレンニッパーは1999年に、プロトコルの最初のバージョンを執筆している。
仕様[編集]
仕様はロイヤリティフリーで公開されていて、現在の仕様は3.1となっている。[1]
特徴[編集]
MQTTには、次のような特徴がある。
軽量なプロトコル[編集]
プロトコル電文仕様は、軽量でシンプルになっている。
- ヘッダーサイズが最小で2byte
- シンプルなプロトコルシーケンス
柔軟性の高いメッセージ配布(Sub：購読)[編集]
配布先条件が"/"区切りの階層構造になっており、さらにワイルドカードによる指定ができる。配布先はそのパターンにマッチした宛先になる。
- TopicベースでのPub/Sub
- 1対1、1対N、N対Nのメッセージ配布
メッセージ配布の品質[編集]
アプリケーションの特性に合わせて三種類のQoS（Quality of Service）レベルの指定ができる。
- QoS0：最高１回
- メッセージが確実に届く保証はない
- メッセージ配布に失敗しても再送をしない
- QoS1：最低１回
- 必ずメッセージ配布するが、重複する可能性がある
- QoS2：正確に１回
- 必ずメッセージを配布して、重複も発生しない
メッセージ再配布機能[編集]
メッセージ再配布機能（Durable subscribe）は、次のフローで処理される。
- 意図せずにSubscriber（メッセージ配布者）通信が切断
- その後、当該のSubscriberが再接続
- 切断から再接続までに発生したメッセージを再送処理
- QoS1,2のメッセージを再配布する
Last Will and Testament[編集]
Retain[編集]
- ブローカーが最後に配布したメッセージは必ず保存する
ブローカー[編集]
MQTTをサポートするブローカー（MQサーバ）は数多くある。それぞれのサーバがサポートする機能には、基本機能の他、サーバ特有の機能がある[2]。
主なMQTTブローカーには以下のようなものがある。
OSS[編集]
- Mosquitto
- RabbitMQ（Pluginが必要）
商用[編集]
- IBM MessageSight（ハードウェア）
- IBM WebSphere MQ Telemetry
- 時雨堂 Akane
メッセージタイプ[編集]
Connect[編集]
サーバーとの接続が確立されるのを待機し、ノード間でリンクを作る。
Disconnect[編集]
MQTTクライアントが必要な処理を完了し、TCP/IPセッションが切断されるのをするのを待機する。
Publish[編集]
リクエストをMQTTクライアントに渡した後、アプリケーションスレッドに即座に戻る。
使用しているプロジェクト[編集]
現実の世界では、MQTTを実装するプロジェクトの数がある。
Facebook Messenger[編集]
FacebookのメッセンジャーにMQTTを使用している。
IECC Scalable[編集]
IECCシグナリング制御システムのDeltaRailの最新バージョンでは、システムとシグナリングシステムの他の構成要素のさまざまな部分内の通信のためのMQTTを使用している。
外部リンク[編集]
- ^ [1] MQ Telemetry Transport (MQTT) V3.1 プロトコル仕様
- ^ MQTT Broker Feature Comparison Feature comparison of the most popular MQTT brokers.
