今回からは、MQTTバージョン5のWD11をもとに、旧バージョン3.1.1からの差分を解説します。長いので３回に分割しています。

2017/3/19更新 3.1.2.12.1 Session Stateの記述は、従来バージョンの3.1.2.4 Clean Sessionの記述の一部と同様だったので、削除しました。

連載目次

[第1回 標準化の狙い] (http://qiita.com/items/bd21ce2995f313521c56) (2017/2/25)
[第2回 旧バージョンからの主な変更点 1〜3.2] (http://qiita.com/items/71f1e4f4e40d0033822d) (2017/3/9)
[第3回 旧バージョンからの主な変更点 3.3〜3.15]
(http://qiita.com/items/563f2c67639318c5c3d6) (2017/3/12)
[第4回 旧バージョンからの主な変更点 4〜] (http://qiita.com/items/8cf99f01a4dc1530a137) (2017/3/18)
[第5回 考察 MQTTはIoTにおいてHTTP/RESTを完全に駆逐する] (http://qiita.com/items/00cb2050ae68b45bb931) (2017/3/18)

以下では、主要な変更点を、標準書の項番単位で紹介していきます。

1. Introduction

1.2 Terminology （用語）

• 「共有サブスクリプション」が新規に追加されました。これは、サーバーから、複数のサブスクライバーの中のどれか１つのみに、メッセージがパブリッシュされるというものです。サブスクライバーの負荷分散のために利用されます。
• 「不正パケット」が新規に追加されました。不正パケットに関するエラー処理が厳格になっています。
• 「プロトコルエラー」が新規に追加されました。プロトコルエラーに対してのエラー表現が豊富になっています。

1.5 Data Representation （データ表現）

1.5.2 Four Byte Integer

• 従来は、2バイト整数のみの定義でしたが、4バイト整数も定義されました。

1.5.5 Variable Byte Integer

• 4バイト、268,435,455までの可変バイト整数が新規に追加されました。エンコーディングの方法が特殊で、各バイトの最高ビットが1の時に、継続バイトが存在します。

1.5.6 Binary Data

• 先頭2バイトでデータサイズを表す、可変長バイナリデータが新規に追加されました。

1.6 Security

• 認証認可や各種セキュリティオプションへの対応がSHOULD（推奨）とされました。

2. MQTT Control Packet Format

2.1 Structure of an MQTT Control Packet

2.1.2 MQTT Control Packet type

• DISCONNECTがサーバーからもできるようになりました。
• AUTHタイプが新規に追加されました。

2.1.3 Flags

• AUTHタイプのFlagsは0固定です。

2.1.4 Remaining Length

• パケットの残りバイト数が、可変バイト整数になりました。そのため、非常に長いパケット表現が可能になります。従来も任意仕様として規定はされていましたが、必須になりました。

2.2 Variable Header

2.2.2 Return Code

• 128以上のエラーコードなど、リターンコードが新規に豊富に追加されました。エラーレポートの改善は、本連載の第1回で紹介した「標準化の狙い」の１つです。

2.2.3 Properties

• 様々な追加情報をあらわすプロパティが新規に追加されました。

2.3 Payload

• UNSUBACKのペイロードが必須になりました。

Variable Headerの変更に関する、プロトコル全体共通なことは、以降の説明では省略します。

3. MQTT Control Packets

3.1 CONNECT – Connection Request

3.1.2 Variable Header

3.1.2.2 Protocol Version

• プロトコルレベルが5になりました。バージョン3.1.1の時は4です。

3.1.2.10 Keep Alive

• クライアントからのCONNECT時のキープアライブ設定値を、サーバーはCONNACKにおいて上書きできることになりました。

3.1.2.11 Property Length

• プロパティの追加に対応しました。

3.1.2.12 Session Expiry Interval

• 「セッション」有効期限が新規に追加されました。デフォルト動作として、本プロパティが無い場合、セッションは無期限に継続します。本プロパティが0の場合、ネットワークコネクションとともにセッションは終了します。

3.1.2.13 Will Delay Interval

• WILLメッセージの送信待機時間が新規に追加されました。デフォルト動作として、本プロパティが無い場合、PUBLISH側のネットワークコネクションに意図しない切断があった場合、即座にWILLメッセージがサブスクライバーに送信されます。

3.1.2.14 Receive Maximum

• 同一ネットワークコネクションでのクライアントの最大受信パケット数のバッファサイズが新規に追加されました。サーバは、QoS1または2のPUBLISHにおいて、クライアントからのPUBACKやPUBCOMPの返信が完了していないパケットについて、この最大数までしか送れません。QoS0には制限はありません。デフォルト動作として、本プロパティが無い場合、65535となります。
• これは、低リソースのクライアントを保護するための、フロー制御として機能します。フロー制御については4.9を参照してください。

3.1.2.15 Maximum Packet Size

• クライアントの最大受信パケットサイズが新規に追加されました。デフォルト動作として、本プロパティが無い場合、プロトコル上限までとなります。
• 今回から最大パケットサイズが非常に大きくなったため、クライアントアプリケーション（必ずしもクライアント=デバイスだけではなく、クラウドアプリの場合もあります）側で、最大パケットサイズを制御できるようになったということです。
• 最大サイズ以上のパケットを受け取った場合、クライアントはPacket too largeのエラーコードをDISCONNECTパケットに乗せて返信し、セッションを切断します。

3.1.2.16 Topic Alias Maximum

• クライアントが受信できるTopic Aliasの最大値が新規に追加されました。デフォルト動作として、本プロパティが無い場合、サーバーはTopic Aliasを送信してはいけません。
• Topic Aliasについては、3.3.2.6を参照してください。

3.1.2.17 Request Response Information

• CONNACKにて要求応答の参照情報を返すかどうかを指示する値が新規に追加されました。デフォルト動作として、本プロパティが無い場合、0を指定した場合と同じ動作になります。
• 値が1の場合、サーバーがCONNACKで参照情報を返すことができます。たたし、返さなくてもかまいません。
• 要求応答における応答トピックに関する情報をサーバーが動的に指示をする、といったユースケースが想定されています。ただし、参照情報の具体的な構造は規定されていません。
• 要求応答については4.10を参照してください。

3.1.2.18 Request Problem Information

• 詳細エラー内容を返すかどうかを指示する値が新規に追加されました。デフォルト動作として、本プロパティが無い場合、1を指定した場合と同じ動作となります。
• 値が0の場合、詳細エラー内容は、CONNACKかDISCONNECTでしか通知できません。値が1の場合、任意のパケットで詳細エラー内容が通知できます。

3.1.2.19 User Property

• UTF-8の名前と値のペアからなる、自由に使えるユーザプロパティが新規に追加されました。複数のユーザプロパティ（名前はユニークである必要があります）を1パケットに入れることも可能です。
• 用途は規定されていません。

3.1.2.20 Auth Method

• UTF-8の認証方式名が新規に追加されました。
• クライアントはCONNECTで認証方式を指定した場合、CONNACKを受けるまでは、AUTHパケットかDISCONNECTバケット以外は送信できません。
• 拡張認証がどのように動作するかは4.12を参照してください。

3.1.2.21 Auth Data

• バイナリの認証データが新規に追加されました。

3.2 CONNACK – Connect acknowledgement

3.2.2.3 Connect Return Code

• 詳細なリターンコードが規定されました。

3.2.2.4 Property Length

• プロパティの追加に対応しました。

3.2.2.5 Receive Maximum

• 3.1.2.14と同様に、サーバー側でも最大受信バッファサイズが新規に追加されました。

3.2.2.6 Maximum QoS

• サーバーからクライアントにサポートしている最大QoSを知らせることができるようになりました。従来は、プロトコル上はサーバーはすべてのQoSに対応する前提となっていましたが、これにより、クライアントはサーバーのサポート範囲でのQoSリクエストを送ることがてきます。デフォルト動作として、本プロパティが無い場合、2を指定した場合と同じ動作になります。

3.2.2.7 Retain Available

• サーバーからクライアントにRETAINのサポート有無を伝えることができるようになりました。デフォルト動作として、本プロパティが無い場合、1=サポートあり、を指定した場合と同じ動作になります。

3.2.2.8 Maximum Packet Size

• 3.1.2.15と同様に、サーバー側の最大パケットサイズが新規に追加されました。

3.2.2.9 Assigned Client Identifier

• CONNECT時のクライアントIDが空欄の場合、サーバーからクライアントIDを動的に付与することができるようになりました。

3.2.2.10 Topic Alias Maximum

• 3.1.2.16と同様に、サーバー側で受信できるTopic Aliasの最大値が新規に追加されました。

3.2.2.11 Reason String

• UTF-8文字列での自由なフィールドが新規に追加されました。サーバーからクライアントに接続詳細ログ情報等を伝えるのに使われます。

3.2.2.12 User Property

• 3.1.2.19と同様に、サーバー側でもユーザープロパティが返信できるようになりました。

3.2.2.13 Wildcard Subscription Available

• サーバーからクライアントにワイルドカードでのサブスクリプションのサポート有無を伝えることができるようになりました。デフォルト動作として、本プロパティが無い場合、1=サポートあり、を指定した場合と同じ動作になります。

3.2.2.14 Subscription Identifiers Available

• サーバーからクライアントにサブスクリプションIDのサポート有無を伝えることができます。デフォルト動作として、本プロパティが無い場合、1=サポートあり、を指定した場合と同じ動作になります。
• サブスクリプションIDは本バージョンからの新機能であり、詳細は3.8.4を参照してください。

3.2.2.15 Shared Subscription Available

• サーバーからクライアントに共有サブスクリプションのサポート有無を伝えることができます。デフォルト動作として、本プロパティが無い場合、1=サポートあり、を指定した場合と同じ動作になります。
• 共有サブスクリプションは本バージョンからの新機能であり、詳細は4.8.2を参照してください。

3.2.2.16 Server Keep Alive

• 3.1.2.10にも記載していますが、サーバーはクライアントのキープアライブ設定値を上書きできるようになりました。

3.2.2.17 Response Information

• 3.1.2.17に対応して、サーバーは応答参考情報を返すことが可能になりました。必ずしも返す必要はありません。

3.2.2.18 Server Reference

• サーバのリダイレクト情報を返すことができるようになりました。
• リダイレクトについては4.13を参照してください。

3.2.2.19 Auth Method

• UTF-8の認証方式名が新規に追加されました。
• 拡張認証がどのように動作するかは4.12を参照してください。

3.2.2.20 Auth Data

• バイナリの認証データが新規に追加されました。