要約
ブローカーを実装する際に考慮する点として、ブローカーがパケットを一時保存しなければならないケースが３つあります。QoSとRetainとOffline queueです。
はじめに
MQTTブローカーを実装するにあたり、ソフトウェアとして破綻無き設計するには、MQTT プロトコルが「データの送達」と「保存」についてどのように規定しているかを理解する必要がありました。本記事では、規格を見ながら整理します。
[前提]切断について
MQTT over TCPと前提だとすると、ブローカーアプリケーションから見る場合ネットワークのソケットに書き込んだデータが必ず相手のアプリケーションまで送達するとは限りません。TCPにはTCP Keepalive や TCP の接続状態（ESTABLISHED など）の接続された状態を表す仕組みはありますが、それでもアプリケーションレベルにおいて、「切断された＝アプリケーションがデータ送信不能」を即時検知できるわけではありません。
QoS
切断や不達のリスクに対して、MQTT では「メッセージ送達品質（QoS: Quality of Service）」という仕組みを定義しています。QoSはPublish時とSubscribe時に指定の機会がありますが、PubとSubでは意味合いが異なり、Subで指定するのは受け取る際の最大QoSです。「Publish されたメッセージの QoS」と「サブスクリプションで指定された最大 QoS（Maximum QoS）」のうち、低い方が実際の配送 QoS になります。
The QoS of Application Messages sent in response to a Subscription MUST be the minimum of the QoS of the originally published message and the Maximum QoS granted by the Server [MQTT-3.8.4-8].
また、QoSはクライアントとサーバ間でのやりとりの話であり、他のクライアントへのQoSのシーケンスとは独立して進行します。つまり、Pubcompはあくまでもブローカーにデータが送達完了したということであり、他のレシーバーへの送達が完了したわけでも、他のレシーバーへの送達はPubcompを待たなければいけないわけではありません。
The receiver is not required to complete delivery of the Application Message before sending the PUBREC or PUBCOMP. When its original sender receives the PUBREC packet, ownership of the Application Message is transferred to the receiver.
| QoS | 保証レベル |
|---|---|
| 0 | 最多1回 |
| 1 | 少なくとも1回 |
| 2 | ちょうど1回 |
QoS1/2のパケットの流れ
QoS1
クライアントがパブリッシュする場合
PUBACKは対応するPUBLISHと同じPacket Identifierを持つ必要があります
[MQTT-2.3.1-6]
A PUBACK, PUBREC or PUBREL Packet MUST contain the same Packet Identifier as the PUBLISH Packet that was originally sent.
QoS2
QoS1/2のシーケンス中の切断
シーケンス中の不達に対しては再接続後に再送する必要があります。ここでいう「不達」とは、単にソケット書き込みが失敗することだけでなく、プロトコル上の応答（PUBREC や PUBCOMP など）が返ってこないケースも含みます。PUBREC が来ないなら、PUBLISH再送、PUBCOMPが来ないならPUBREL再送となるわけです。再送の場合はDUPフラグを立てて送信する必要があります。
Retain
RetainとはトピックごとにPublishedされたメッセージを保持する機能です。
他のデータやクライアントからそのトピックにPublishしたら、その値で更新されます。そして、Subscribeが来た場合に、そのTopicfilterがRetainにあるTopicとマッチしている全てのパケットを送信する必要があります。
Payload lengthが0のPUBLISHでretain flagが1の場合、ブローカーはそのトピックの retain message を削除します。
If the Payload contains zero bytes it is processed normally by the Server but any retained message with the same topic name MUST be removed and any future subscribers for the topic will not receive a retained message [MQTT-3.3.1-6]
Offline queue : 不在着信
クライアントがトピックをサブスクライブしたあとに切断された場合、QoS1/2のメッセージに限り、ブローカーは一時的に配送されるはずのメッセージを保存しておかなければなりません。
それはクライアントから送信されるConnectパケットのCleanSession flagによって「以前のセッションを消去し、今後保存もしない」か、「以前のセッションを再利用し、今後も保存する」かを選ぶことができます。
If the CleanSession flag is set to 1, the client and server must discard any previous session and not store any session state after disconnection.
まとめ、ブローカーを実装する場合の考慮点
- ブローカーがパケットを保存しなければならないケースは３つあり、QoSとRetainとOffline queue
- HTTPとは異なり、接続の維持・データの不達を意識して実装する
- データを保存しておく必要がある、その場合揮発していいのか、サーバサイドでクラスタを組む場合どのようなロジックになるのかを考える
(おまけ)個人的なmqttについてのモチベーション
MQTTをサーバ側で利用する場合、OSS/商用ブローカーを使うのが一般的ですが、HTTPのように自由に抽象化できる仕組みが少ないと感じていました。
そこで、「HTTPのAPIを設計するように MQTT の応答を記述できるフレームワーク」を目指して開発しています。
本記事では、まず ブローカー実装の過程でつまづいた規格上の考慮点 を整理してみました。
フレームワーク自体の設計や狙いについては、機会があれば別の記事で！
著作権表記
規格引用部分について、https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html
Notices Copyright © OASIS Open 2019. All Rights Reserved. All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so. OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims. The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark for above guidance.