はじめに
VPoPの岩田です。本記事は、先日開始したMQTT5連載の第2回目になります。
すでに公開されている連載記事は、以下のリンクからご覧いただけます。
第2回目の本記事では、MQTT Version 5.0での変更点のサマリーをご紹介します。 MQTT Version 5.0でのおもな変更点は、OASIS標準仕様書 の末尾Appendix Cにまとめられていますので、こちらをひとつずつ日本語に翻訳して紹介したいと思います。
なお翻訳については、なるべく文意がわかりやすくなるよう直訳ではなく意訳していますので、誤訳等心配な場合は原文もあわせてご確認ください。
それぞれの項目は、次回以降の連載で詳しく解説していきます。
- はじめに
- 当社プロダクトの簡単なご紹介
- MQTT Version 5.0 での変更点
- Session Expiry | セッションの有効期限
- Message Expiry | メッセージの有効期限
- Reason Code on All ACKs | 全ACKに付与される理由コード
- Reason String on All ACKs | 全ACKに付与される理由文字列
- Server Disconnect | サーバーからの切断
- Payload Format and Content Type | ペイロード形式とコンテンツタイプ
- Request / Response | リクエスト・レスポンスパターン
- Shared Subscriptions | 共有サブスクリプション
- Subscription ID | サブスクリプション識別子
- Topic Alias | トピックエイリアス
- Flow Control | フロー制御
- User Properties | ユーザープロパティ
- Maximum Packet Size | 最大パケットサイズ
- Optional Server Feature Availability | サーバーのオプション機能の利用可否
- Enhanced Authentication | 改良された認証機能
- Subscription Options | サブスクリプション用オプションの追加
- Will Delay | Willメッセージの発出遅延
- Server Keep Alive | サーバーからのKeep Aliveの指定
- Assigned ClientID | サーバーからのクライアントIDの付与
- Server Reference | 他のサーバーへの誘導
- おわりに
- 著作権等に関するお知らせ
当社プロダクトの簡単なご紹介
弊社アプトポッドでは、IoTシステムの通信バックエンドとしてデファクトスタンダードとなっているMQTTに代わる選択肢として、独自開発の通信ミドルウェア「intdash」 を開発・提供しています。 intdashでは、MQTTの旧バージョンであるMQTT 3.1.1が抱えていたスケーラビリティやパフォーマンスに関わる課題を、MQTT5とは異なるアプローチによって解決しています。
intdashについては、連載1日目の記事でも簡単に触れていますので、よろしければこちらの記事もご覧ください。
また、intdashで使用している当社独自の通信プロトコルについても以下の記事で解説していますので、こちらも併せてご覧ください。
また、システム構築の受託やご相談も受け付けておりますので、IoTシステムの構築でなにかお困りのことがあれば、お気軽に弊社までお問い合わせください。
それでは、本編に入っていきます。
MQTT Version 5.0 での変更点
Session Expiry | セッションの有効期限
Split the Clean Session flag into a Clean Start flag which indicates that the session should start without using an existing session, and a Session Expiry interval which says how long to retain the session after a disconnect. The session expiry interval can be modified at disconnect. Setting of Clean Start to 1 and Session Expiry Interval to 0 is equivalent in MQTT v3.1.1 of setting Clean Session to 1.
Clean Session フラグを、既存のセッションを使用せずにセッションを開始することを示すClean Startフラグと、切断後にセッションを保持する期間を示すSession Expiry Intervalに分割しました。Session Expiry Intervalは切断時に変更できます。Clean Startを1に設定し、Session Expiry Intervalを0に設定することは、MQTT v3.1.1でClean Sessionを1に設定することと同等です。
Message Expiry | メッセージの有効期限
Allow an expiry interval to be set when a message is published.
メッセージが公開される際に、有効期限を設定できるようになりました。
Reason Code on All ACKs | 全ACKに付与される理由コード
Change all response packets to contain a reason code. This include CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK, DISCONNECT, and AUTH. This allows the invoker to determine whether the requested function succeeded.
すべての応答パケットに理由コードを含めるように変更しました。これにはCONNACK、PUBACK、PUBREC、PUBREL、PUBCOMP、SUBACK、UNSUBACK、DISCONNECT、AUTHが含まれます。これにより、要求された機能が成功したかどうかを呼び出し元が判断できます。
Reason String on All ACKs | 全ACKに付与される理由文字列
Change most packets with a reason code to also allow an optional reason string. This is designed for problem determination and is not intended to be parsed by the receiver.
理由コードを含むほとんどのパケットに、オプショナルな理由文字列も追加できるように変更しました。これは問題の切り分けや特定のために設計されており、受信者によってパースされることを意図していません。
Server Disconnect | サーバーからの切断
Allow DISCONNECT to be sent by the Server to indicate the reason the connection is closed.
サーバーがDISCONNECTを送信し、接続が閉じられた理由を示すことを可能にしました。
Payload Format and Content Type | ペイロード形式とコンテンツタイプ
Allow the payload format (binary, text) and a MIME style content type to be specified when a message is published. These are forwarded on to the receiver of the message.
メッセージが公開される際に、ペイロードフォーマット（バイナリまたはテキスト）と、MIME形式のコンテンツタイプを指定できるようにしました。これらはメッセージの受信者に転送されます。
Request / Response | リクエスト・レスポンスパターン
Formalize the request/response pattern within MQTT and provide the Response Topic and Correlation Data properties to allow response messages to be routed back to the publisher of a request. Also, add the ability for the Client to get configuration information from the Server about how to construct the response topics.
MQTTでのリクエスト/レスポンスパターンを正式仕様とし、Response TopicとCorrelation Dataプロパティを提供して、レスポンスメッセージをリクエストの発行者に返信できるようにします。また、どのようにレスポンストピックを構築すればよいかを、クライアントがサーバーから取得する機能を追加しました。
Shared Subscriptions | 共有サブスクリプション
Add shared subscription support allowing for load balanced consumers of a subscription
負荷分散のために1つのサブスクリプションを複数のコンシューマーでサブスクライブすることを可能にする、共有サブスクリプションのサポートを追加しました。
Subscription ID | サブスクリプション識別子
Allow a numeric subscription identifier to be specified on a SUBSCRIBE, and returned on the message when it is delivered. This allows the Client to determine which subscription or subscriptions caused the message to be delivered.
サブスクライブの際に数値のサブスクリプション識別子を指定し、メッセージを受信する際にその識別子を受け取ることができます。これにより、クライアントはそのメッセージがどのサブスクリプションのの結果として配信されたのかを判断できます。
Topic Alias | トピックエイリアス
Decrease the size of the MQTT packet overhead by allowing the topic name to be abbreviated to a small integer. The Client and Server independently specify how many topic aliases they allow.
トピック名に小さな整数値を割り当てて省略することで、MQTTパケットのオーバーヘッドのサイズを減らすことができます。クライアントとサーバーは、それぞれが許可するトピックエイリアスの最大数を独立して指定します。
Flow Control | フロー制御
Allow the Client and Server to independently specify the number of outstanding reliable messages (QoS>0) they allow. The sender pauses sending such messages to stay below this quota. This is used to limit the rate of reliable messages, and to limit how many are in flight at one time.
QoSが1以上の信頼性のあるメッセージについて、未処理のメッセージ数をクライアントとサーバーが独立して設定できるようにします。送信者は、この割り当てを下回るようにQoS 1以上のメッセージの送信を止めます。これは、QoSが1以上の信頼性のあるメッセージのレートを制限し、同時にin-flightとなるメッセージ数を制限するために使用されます。
User Properties | ユーザープロパティ
Add User Properties to most packets. User properties on PUBLISH are included with the message and are defined by the Client applications. The user properties on PUBLISH and Will Properties are forwarded by the Server to the receiver of the message. User properties on the CONNECT, SUBSCRIBE, and UNSUBSCRIBE packets are defined by the Server implementation. The user properties on CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK and AUTH packets are defined by the sender, and are unique to the sender implementation. The meaning of user properties is not defined by MQTT.
ほとんどのパケットにユーザープロパティを追加します。PUBLISHメッセージのユーザープロパティは、クライアント側のアプリケーションによって定義され、メッセージに含められます。PUBLISHメッセージのユーザープロパティとWillのプロパティはサーバーによって転送され、受信者まで届けられます。CONNECT、SUBSCRIBE、UNSUBSCRIBEメッセージのユーザープロパティは、サーバーの実装によって定義されます。CONNACK、PUBACK、PUBREC、PUBREL、PUBCOMP、SUBACK、UNSUBACK、AUTHメッセージのユーザープロパティは、送信者によって定義され、送信者の実装ごとに異なります。ユーザープロパティの意味は、MQTTによっては定義されていません。
Maximum Packet Size | 最大パケットサイズ
Allow the Client and Server to independently specify the maximum packet size they support. It is an error for the session partner to send a larger packet.
クライアントとサーバーが、それぞれがサポートする最大パケットサイズを独立して指定できるようにします。セッションを張っている相手が最大サイズより大きなパケットを送信することはエラーとして扱われます。
Optional Server Feature Availability | サーバーのオプション機能の利用可否
Define a set of features which the Server does not allow and provide a mechanism for the Server to specify this to the Client. The features which can be specified in this way are: Maximum QoS, Retain Available, Wildcard Subscription Available, Subscription Identifier Available, and Shared Subscription Available. It is an error for the Client to use features that the Server has declared are not available.
It is possible in earlier versions of MQTT for a Server to not implement a feature by declaring that the Client is not authorized for that function. This feature allows such optional behavior to be declared and adds specific Reason Codes when the Client uses one of these features anyway.
サーバーが許可しない機能セットを定義し、サーバーがクライアントにこれを指定するメカニズムを提供します。このように指定できるのは、最大のQoS、Retainが利用可能か、ワイルドカードサブスクリプションが利用可能か、サブスクリプション識別子が利用可能か、共有サブスクリプションが利用可能か、などの機能です。サーバーが利用不可と宣言した機能を、クライアントが使用することはエラーとして扱われます。
MQTTの以前のバージョンでは、その機能に対してクライアントが認証されていないと宣言することで、サーバーがその機能を実装しない選択肢を取ることができました。この機能は、そのようなオプショナルな動作を宣言することを許可し、クライアントがこれらのいずれかの機能を使用した際に特定の理由コードを追加します。
Enhanced Authentication | 改良された認証機能
Provide a mechanism to enable challenge/response style authentication including mutual authentication. This allows SASL style authentication to be used if supported by both Client and Server, and includes the ability for a Client to re-authenticate within a connection.
相互認証を含むチャレンジ/レスポンス形式の認証を可能にするメカニズムを提供します。これにより、クライアントとサーバーの両方がサポートしている場合、SASL形式の認証を使用できるようになります。また、クライアントがコネクション内で再認証することも可能になります。
Subscription Options | サブスクリプション用オプションの追加
Provide subscription options primarily defined to allow for message bridge applications. These include an option to not send messages originating on this Client (noLocal), and options for handling retained messages on subscribe.
主にメッセージブリッジアプリケーション用に定義された、サブスクリプションオプションを提供します。これには、このクライアントで発生したメッセージを送信しないオプション（noLocal）と、サブスクライブ時のRetainされたメッセージの取り扱いに関するオプションが含まれます。
Will Delay | Willメッセージの発出遅延
Add the ability to specify a delay between the end of the connection and sending the will message. This is designed so that if a connection to the session is re-established then the will message is not sent. This allows for brief interruptions of the connection without notification to others.
コネクションが終了してからWillメッセージを送信するまでの間の遅延時間を指定する機能を追加します。これはセッションへの接続が再確立された場合、Willメッセージが送信されないようにするためのものです。これにより、他者に通知することなく、短時間の接続中断が可能になります。
Server Keep Alive | サーバーからのKeep Aliveの指定
Allow the Server to specify the value it wishes the Client to use as a keep alive. This allows the Server to set a maximum allowed keepalive and still have the Client honor it.
クライアントに使用させたいKeep Aliveの値を、サーバーから指定できるようにします。これにより、サーバーは許容可能な最大のKeep Alive値を設定し、クライアントにそれを遵守させることができます。
Assigned ClientID | サーバーからのクライアントIDの付与
In cases where the ClientID is assigned by the Server, return the assigned ClientID. This also lifts the restriction that Server assigned ClientIDs can only be used with Clean Session=1 connections.
ClientIDがサーバによって割り当てられている場合は、割り当てられたClientIDを返します。これにより、サーバから割り当てられたClientIDはClean Session=1でのコネクションでのみ使用できるという制限も解除されます。
Server Reference | 他のサーバーへの誘導
Allow the Server to specify an alternate Server to use on CONNACK or DISCONNECT. This can be used as a redirect or to do provisioning.
CONNACKまたはDISCONNECT時に使用する代替サーバーを、サーバーが指定できるようにします。これはリダイレクトやプロビジョニングに使用できます。
おわりに
本記事では、MQTT Version 5.0での変更点について、OASIS仕様書のAppendix Cの翻訳という形でご紹介しました。 今回ご紹介した各機能は、このあとの連載にて詳細に解説していきます。 次回以降の連載にもご期待ください。
著作権等に関するお知らせ
OASIS標準仕様 には、以下の注意書きがあります。標準文書およびその翻訳の提供には、著作権表示と「Notices」セクションの表示が必要とのことですので、こちらにコピーを記載いたします。
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.
