MQTTv5.0：新機能の概要。パート2

こんにちは！



以下の資料は、MQTTv5.0の新しいバージョンで追加された機能に関する記事の続きです。すでに学習している場合は、新しい関数のほとんどがパッケージに追加できるプロパティの概念に基づいていることに気付くのは難しいことではありません。この記事では、それらを詳細に分析します。



約 -この記事は、MQTTの複雑さに興味を持っているか、深く掘り下げる必要がある人を対象としています。ここには写真や叙情的な逸脱はなく、ハードコアだけです!!!



以下は、すべてのプロパティの表です（仕様のセクション2.2.2.2を参照）。







それでは、それらを詳しく見てみましょう。

ペイロードフォーマットインジケータ-ペイロードフォーマットインジケータ

• 0-データは未定義のバイトのセットであり、ペイロードフォーマットインジケータを送信しないのと同じです。
  
  
• 1-データはUTF-8でエンコードされた文字データです。
  
  

メッセージの有効期限-メッセージの有効期限

メッセージの有効期限間隔（秒単位）を表す数値。



メッセージの有効期限が経過し、サーバーがメッセージを正しいサブスクライバーに配信できなかった場合、サーバーはそのサブスクライバーのメッセージを削除する必要があります。

コンテンツタイプ-コンテンツタイプ

コンテンツタイプの値は、送信クライアントと受信クライアントによって決定されます。

応答トピック-応答のトピック

返信メッセージのトピックとして使用されるUTF-8文字列。



返信にトピックが指定されたメッセージの受信者は、このトピックを公開のトピックとして使用して返信を送信します。



この場合の要求/応答の相互作用は次のように発生します（仕様の4.10.1節を参照）。

1. クライアント（送信者）は、応答のトピックを指定するトピックを含む要求メッセージを公開します。
   
   
2. () , , . . , .
   
   
3. , , .
   
   
4. . - . , .
   
   

Correlation Data —

相関データは、要求メッセージの送信者が、応答メッセージが受信されたときにどの要求に属するかを判別するために使用されます。相関データがない場合、リクエスターは相関データを必要としません。



要求メッセージに相関データが含まれている場合、受信者は、応答メッセージのPUBLISHパケットにプロパティとして相関データも含める必要があります。



相関データ値は、要求メッセージの送信者と応答メッセージの受信者にのみ意味があります。

サブスクリプション識別子-サブスクリプション識別子

サブスクリプションIDを表す番号。



パブリケーションが複数のサブスクリプションとの一致の結果である場合、複数のサブスクリプションIDが指定されます。その場合、それらの順序は重要ではありません。



顧客は、特定の出版物に一致する複数のサブスクリプションを作成し、それらの複数に同じ識別子を使用することもできます。この場合、PUBLISHパッケージには複数の同一のサブスクリプションIDが含まれます。



サブスクリプションIDは、SUBSCRIBEパッケージの結果として作成または変更されたサブスクリプションに関連付けられています。サブスクリプションIDがある場合は、サブスクリプションとともに保存されます。このプロパティが指定されていない場合、サブスクリプションはサブスクリプションとともに保存されません。



サブスクリプションIDはサーバー上のセッション状態の一部であり、対応するPUBLISHパケットを受信するクライアントに返されます。これらは、サーバーがUNSUBSCRIBEパケットを受信したとき、サーバーが同じトピックフィルターのSUBSCRIBEパケットをクライアントから受信したが、サブスクリプションIDが異なるか、サブスクリプションIDがない場合、またはサーバーがCONNACKパケットでSession Present 0を送信した場合に、サーバーセッション状態から削除されます。

セッションの有効期限間隔-セッションの有効期限

セッションを期限切れにする間隔（秒単位）を表す数値。



セッションの有効期限間隔がない場合は、値0が使用されます。0に設定されているか存在しない場合、セッションはネットワーク接続が閉じられたときに終了します。



セッションの有効期限間隔が0xFFFFFFFF（UINT_MAX）の場合、セッションは有効期限が切れません。



セッションの有効期限間隔が0より大きい場合、クライアントとサーバーは、ネットワーク接続が閉じられた後もセッション状態を維持する必要があります。クライアント



は、断続的な接続を提供するネットワークを介してサーバーに接続できます。このクライアントは、短いセッション有効期限間隔を使用できるため、ネットワークが再び利用可能になったときに再接続し、メッセージを確実に配信し続けることができます。クライアントに接続を復元する時間がない場合、メッセージは失われます。



Clean Startを1に設定し、有効期限間隔を0に設定することは、MQTT仕様バージョン3.1.1でCleanSessionを1に設定することと同じです。Clean Startを0に設定し、セッションの有効期限を設定しないことは、MQTT仕様バージョン3.1.1でCleanSessionを0に設定することと同じです。

割り当てられたクライアント識別子-割り当てられたクライアント識別子

サーバーによって割り当てられたクライアントIDである文字列。CONNECTパケットで長さがゼロのクライアント識別子が使用された場合に使用されます。

サーバーキープアライブ-キープアライブサーバー

サーバーによって割り当てられたKeepAlive時間を定義する番号。サーバーがCONNACKパケットでServerKeep Aliveを返す場合、クライアントは、KeepAliveとして送信した値の代わりにその値を使用する必要があります。サーバーがServerKeep Aliveを送信しない場合、サーバーはCONNECTパケットでクライアントによって設定されたKeepAlive値を使用する必要があります。



サーバーでのサーバーキープアライブの主な用途は、クライアントが指定したキープアライブがタイムアウトする前に、非アクティブの場合にクライアントを切断することをクライアントに通知することです。

認証方法-認証方法

拡張認証に使用される認証方法の名前を含む文字列。



認証方法がない場合、拡張認証は実行されません。



認証方法は、認証データおよびCONNECTの他のフィールドで送信されるデータの意味、および認証を完了するためにクライアントとサーバーが必要とする交換と処理に関するクライアントとサーバー間の合意です。認証方法は通常、SASLメカニズムです。

認証データ-認証データ

認証データを含むバイナリデータ。認証方法が指定されている場合にのみ送信されます。このデータの内容は、認証方法によって決定されます。

リクエストの問題情報-リクエストの問題に関する情報

クライアントはこの値を使用して、理由文字列またはカスタムプロパティが失敗時にディスパッチされるかどうかを示します。

• 0-サーバーは、CONNACKまたはDISCONNECTパッケージで理由文字列またはカスタムプロパティを返すことができますが、PUBLISH、CONNACK、またはDISCONNECT以外のパッケージで理由文字列またはカスタムプロパティを送信しないでください。
  
  
• 1-サーバーは、許可されている場合、任意のパッケージの理由文字列またはカスタムプロパティを返すことができます。
  
  

遅延間隔-メッセージ遅延間隔

意志メッセージの遅延の間隔を表す数値（秒単位）。遅延間隔がない場合、デフォルトは0であり、Willメッセージが公開されるまでの遅延はありません。



サーバーは、遅延間隔が満了するか、セッションが終了するかのいずれか早い方まで、メッセージの投稿を遅らせます。遅延間隔が切れる前にこのセッションへの新しいネットワーク接続が確立された場合、サーバーは意志メッセージを送信してはなりません。



これを使用する1つの方法は、ネットワークから一時的に切断され、メッセージが公開される前にクライアントが再接続してセッションを続行できる場合に、意志メッセージの公開を防ぐことです。

応答情報の要求-応答の情報を要求します

値が0または1のバイト。クライアントはこの値を使用して、サーバーにCONNACK応答情報を要求します。

• 0-サーバーは応答情報を返さないはずです。
  
  
• 1-サーバーはCONNACKパケットで応答情報を返すことができますが、クライアントがこの情報を要求した場合でも、これは必須ではありません。
  
  

応答情報-応答の情報

応答トピックを作成するためのベースとして使用されるUTF-8文字列。クライアントが応答情報から応答トピックを作成する方法は、この仕様では定義されていません。



通常、これは、少なくともそのセッションの存続期間中、このクライアント用に予約されているトピックのグローバルに一意のサブセットを送信するために使用されます。このメカニズムを使用すると、この構成を各クライアントではなくサーバーで1回実行できます。

サーバーリファレンス-サーバーへのリンク

使用中の別のサーバーを識別するためにクライアントが使用できる文字列。この文字列の値は、スペースで区切られたリンクのリストです。リンクの形式は規制されていません。



サーバーは、「別のサーバーを使用する」または「サーバーを移動しました」という理由コードを指定してCONNACKまたはDISCONNECTを送信することにより、クライアントが別のサーバーを使用するように要求できます。これらのコードの1つを送信する場合、サーバーには、クライアントが使用する必要がある1つまたは複数のサーバーの場所を示すサーバー参照プロパティを含めることもできます。

• 別のサーバーを使用する-別のサーバーを使用するには、クライアントを一時的に切り替える必要があります。
  
  
• サーバーの移動-クライアントは常に別のサーバーに接続する必要があります。
  
  

各リンクは、名前の後にコロンとポート番号を付けて構成することをお勧めします。名前にコロンが含まれている場合、名前の文字列を角括弧で囲むことができます。角括弧で囲まれた名前には、右角括弧文字（ "]"）を含めることはできません。これは、コロンを区切り文字として使用するIPv6アドレスを表すために使用されます。



サーバーリンク内の名前は通常、ホスト名、DNS名、SRV名、またはIPアドレスです。コロンの後の値は通常、10進数のポート番号です。ポート情報が名前から取得される場合（たとえば、SRVの場合）、またはデフォルトの場合、これは必要ありません。



複数のリンクが指定されている場合、クライアントはそのうちの1つを選択する必要があります。

理由文字列-理由文字列

この応答に関連する理由を説明する文字列。サーバーはこの値を使用して、クライアントに追加情報を提供します。



クライアントでの理由文字列の正しい使用には、クライアントコードによってスローされた例外でのこの情報の使用、または理由文字列のログ記録が含まれます。

受信最大値-QOSパケット数の最大値> 0

PUBACK（QoS 1の場合）またはPUBCOMP（QoS 2の場合）を受信せずに送信できるPUBLISH QOS> 0パケットの数を制限するために使用される送信クォータを設定する数値。つまり、この値は、同時に送信されるQoS1およびQoS2パブリケーションの数を制限するために使用されます。まだ応答を受信して​​いない受信最大メッセージが送信されている場合、クライアント/サーバーはQoS1およびQoS2でメッセージを送信しないでください。受信最大値に達すると、QoS 0でのパケットの送信も一時停止できますが、必須ではありません。同時に、PUBLISH以外のパケットの送信を遅らせる必要はありません。



クライアントとサーバーの両方がReceiveMaximumを1に設定している場合、同時に「進行中」のメッセージが1つだけであることを確認します。



指定された値は現在のネットワーク接続にのみ適用され、再接続時に再初期化されます。



指定しない場合、デフォルトで65,535になります。

トピックエイリアス最大-トピックエイリアスの最大値

トピックエイリアスの最大値を表す数値。



この値は、トピックエイリアスとして受け入れられる最大値を示します。これは、この接続で保存する必要があるトピックエイリアスの数を制限するために使用されます。

トピックエイリアス-トピックエイリアス

PUBLISHパケットのサイズを小さくするために、送信者はトピックエイリアスを使用できます。これは、トピック名を使用する代わりにトピックを識別するために使用される整数値です。この手法は、PUBLISHパケットのサイズを縮小し、トピック名が長く、同じ名前がネットワーク接続で再利用されることが多い場合に役立ちます。



受信者側では、トピックのエイリアスを受信すると、トピックとそのエイリアスの間に必要な対応が確立されます。



PUBLISHパッケージにトピックエイリアスが含まれている場合、レシーバーはそれを次のように処理します（仕様のセクション3.3.4を参照）。

1. ,
   
   a) , , ,
   
   b) , , , .
   
   
2. ,
   
   a) ,
   
   b) , .
   
   

Maximum QoS — QoS

0または1にすることができます。最大QoSがない場合、クライアントは最大QoS 2を使用し



ます。サーバーがPUBLISHQoS1またはQoS2パケットをサポートしない場合、サポートする最高のQoSを示すCONNACKパケットで最大QoSを送信する必要があります。



クライアントがサーバーから最大QoSを受信した場合、指定された最大値を超えるQoSレベルのPUBLISHパケットを送信しないでください。

利用可能な保持-保存が可能です

• 0-保存されたメッセージはサポートされていません。
  
  
• 1-保存されたメッセージがサポートされます。
  
  

サーバーからRetainAvailable値0を受信するクライアントは、RETAINフラグが1に設定されたPUBLISHパケットを送信してはなりません（MUSTNOT）。

ユーザープロパティ-ユーザープロパティ

これは、文字列ペア「名前」-「値」です。このプロパティは、他のプロパティとは異なり、複数回表示される可能性があります。複数のプロパティに同じ名前を使用できます。



このプロパティは、追加の診断またはその他の情報を提供するために使用できます。



これらのプロパティの意味は仕様で指定されておらず、それらの意味と解釈は送信側と受信側のクライアントにのみ知られています。

最大パケットサイズ-最大パケットサイズ

クライアント/サーバーが受け入れることをいとわない最大パケットサイズを定義する数値。パケットサイズは、MQTTパケットの合計バイト数です。このプロパティは、この制限を超えるパケットが処理されないことを示すために使用されます。



最大パケットサイズがない場合、パケットサイズの制限はありません。



パケットサイズを制限することを選択した場合、適切な最大パケットサイズ値を選択するのはアプリケーションの責任です。

ワイルドカードサブスクリプションが利用可能-ワイルドカードサブスクリプションが利用可能

• 0-ワイルドカードサブスクリプションはサポートされていません。
  
  
• 1-そのようなサブスクリプションがサポートされています。
  
  

プロパティが欠落している場合、ワイルドカードサブスクリプションがサポートされます。



サーバーがワイルドカードサブスクリプションをサポートしている場合でも、ワイルドカードサブスクリプションを含む特定のサブスクリプション要求を拒否できます。

利用可能なサブスクリプション識別子-サブスクリプション識別子が利用可能です

• 0-サブスクリプションIDはサポートされていません。
  
  
• 1-サブスクリプションIDがサポートされています。
  
  

プロパティが欠落している場合、サブスクリプションIDがサポートされます。

利用可能な共有サブスクリプション-利用可能な共有サブスクリプション

• 0-一般サブスクリプションはサポートされていません。
  
  
• 1-一般的なサブスクリプションがサポートされています。
  
  

プロパティが欠落している場合は、一般的なサブスクリプションがサポートされます。

結論

この記事は、上記の新しい機能をIoTプラットフォームのサービスに組み込む作業中に生まれたことを思い出してください。また、クライアントから受け取ったプロパティの表示をオブジェクトインターフェイスに表示すると非常に便利だと思いました（オブジェクトの詳細については、こちらをご覧ください>>>）。興味のないプロパティを非表示にしたり、表示するカスタムプロパティを追加したりできます。一般的にはこんな感じです。 おそらくそれだけです。機能をテストするために、このプロジェクトredboltz / mqtt_cppは非常に便利で明確であることがわかりました。 コメントで、バージョン5.0をサポートするMQTTクライアントの他のオープンソースプロジェクト（GUIありとなしの両方）を共有していただければ幸いです。