それぞれの WebSphere MQ Telemetry Transport コマンド・メッセージのメッセージ・ヘッダーには、固定ヘッダーが含まれています。 以下の表は、固定ヘッダーの形式を示しています。
ビット | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
---|---|---|---|---|---|---|---|---|
バイト 1 | メッセージ・タイプ | DUP フラグ | QoS レベル | RETAIN | ||||
バイト 2 | 残りの長さ |
「メッセージ・タイプ」および「フラグ (Dup、QoS レベル、および RETAIN)」フィールドが含まれます。
(最低 1 バイト) 「残りの長さ」フィールドが含まれます。
これらのフィールドについて、以下のセクションで説明します。 データ値はすべてビッグ・エンディアン順であり、高位のバイトは低位のバイトに優先します。 16 ビットの語は、後に最下位バイト (LSB) が続く最上位バイト (MSB) としてワイヤー上に表示されます。
4 ビットの符号なし値として表示されます。このバージョンのプロトコルの列挙は、以下の表で示しています。
ニーモニック | 列挙 | 説明 |
---|---|---|
予約済み | 0 | 予約済み |
CONNECT | 1 | ブローカーへ接続するためのクライアント要求 |
CONNACK | 2 | 接続の確認通知 |
PUBLISH | 3 | Publish メッセージ |
PUBACK | 4 | パブリッシュの確認通知 |
PUBREC | 5 | パブリッシュを受信 (確実送達のパート 1) |
PUBREL | 6 | パブリッシュのリリース (確実送達のパート 2) |
PUBCOMP | 7 | パブリッシュの完了 (確実送達のパート 3) |
SUBSCRIBE | 8 | クライアントのサブスクライブ要求 |
SUBACK | 9 | サブスクライブの確認通知 |
UNSUBSCRIBE | 10 | クライアントのアンサブスクライブ要求 |
UNSUBACK | 11 | アンサブスクライブの確認通知 |
PINGREQ | 12 | PING 要求 |
PINGRESP | 13 | PING 応答 |
DISCONNECT | 14 | クライアントが切断 |
予約済み | 15 | 予約済み |
バイト 1 の残りのビットには、フィールド DUP、QoS、および RETAIN が含まれます。ビット位置は、以下の表に示されているようにフラグを表すためにエンコードされています。
ビット位置 | 名前 | 説明 |
---|---|---|
3 | DUP | 送達の重複 |
2-1 | QoS | サービス品質 |
0 | RETAIN | RETAIN フラグ |
位置: バイト 1、ビット 3。
このフラグは、クライアントやブローカーが PUBLISH メッセージを再送達しようとしたときに設定されます。これは、QoS の値がゼロ (0) よりも大きくて確認通知が必要なメッセージに適用されます。DUP ビットが設定されると、変数ヘッダーにはメッセージ ID が含まれます。
位置: バイト 1、ビット 2-1。
このフラグは、PUBLISH メッセージを確実に送達するためのレベルを示します。 QoS レベルについては、以下の表で示しています。
QoS 値 | ビット 2 | ビット 1 | 説明 | ||
---|---|---|---|---|---|
0 | 0 | 0 | 最大で一回 | 応答不要送信 | <=1 |
1 | 0 | 1 | 最低で一回 | 確認された送達 | >=1 |
2 | 1 | 0 | 一回だけ | 確実送達 | =1 |
3 | 1 | 1 | 予約済み |
位置: バイト 1、ビット 0。
設定されると、RETAIN フラグは、ブローカーがメッセージを保持し、そのメッセージをこのトピックの新しいサブスクライバーへの初期メッセージとして送信することを示します。これは、ブローカーに接続している新しいクライアントが現在のトピック数を迅速に確立することができることを意味します。 これを利用すると便利なのは、パブリッシャーが「例外ごとにレポート」を基本にしてメッセージを送信するだけの場合です。 この場合、新しいサブスクライバーが特定のトピックについてのデータを受信するまでに、少しの時間がかかる可能性があります。 このデータには、「保存された」または Last Known Good (LKG) という値が含まれています。
1 つ以上のトピックに対する SUBSCRIBE メッセージの送信後、サブスクライバーは SUBACK メッセージを受信し、「保存された」の値になっている新しくサブスクライブしたトピックごとに 1 つのメッセージを受信します。 「保存された」の値は、RETAIN フラグを設定することにより、ブローカーからサブスクライバーに向けてパブリッシュされます。 この場合、元々パブリッシュされたときと同じ QoS になります。 さらに、通常の QoS 送達確実性が設定されることになります。 この RETAIN フラグは、メッセージがサブスクライバーによって適切に扱われるように、サブスクライバーへのメッセージ内に設定されて「生」のデータと区別されます。
ブローカーは、前に保存された PUBLISH メッセージをもはや保持していない可能性があるので、サブスクライバーがトピックに関する初期の保存された PUBLISH メッセージを受信するという保証はありません。
位置: バイト 2。
現在のメッセージ内に残っているバイト数を表します。 ここには、変数ヘッダーにあるデータやペイロードも含まれます。
可変長のエンコード・スキームでは、最大 127 バイトの長さのメッセージに 1 バイトが使用されます。 それより長いメッセージは、以下のように処理されます。 残りの長さのデータをエンコードするために各バイトの 7 ビットが使用され、表記の中に後続のバイトがあるかどうかを示すために各バイトの 8 番目のビットが使用されます。 各バイトは 128 の値と「継続ビット」をエンコードすることになります。 例えば、10 進数の 64 という数は、10 進数 64、16 進数 0x40 の 1 バイトでエンコードされます。10 進数の 321 (=128x2 + 65) という数は、より重要ではない方を先頭に 2 バイトでエンコードされます。 最初のバイトは、2+128 = 130 です。 先頭ビットは少なくとも 1 つの後続バイトを示すよう設定されることに注意してください。 2 番目のバイトは 65 です。
このプロトコルでは、表記されるバイト数が最大で 4 に制限されています。 これにより、アプリケーションは 268 435 455 (256 MB) までのメッセージを送信できます。この数が通信で流されるときの表記は、0xFF、0xFF、0xFF、0x7F になります。
以下の表は、増加するバイト数で表される「残りの長さ」の値を示しています。
桁 | 始点 | 終点 |
---|---|---|
1 | 0 (0x00) | 127 (0x7F) |
2 | 128 (0x80、0x01) | 16 383 (0xFF、0x7F) |
3 | 16 384 (0x80、0x80、0x01) | 2 097 151 (0xFF、0xFF、0x7F) |
4 | 2 097 152 (0x80、0x80、0x80、0x01) | 268 435 455 (0xFF、0xFF、0xFF、0x7F) |
10 進数 (X) を可変長エンコード・スキームにエンコードするためのアルゴリズムは、以下のとおりです。
do digit = X MOD 128 x = X DIV 128 // if there are more digits to encode, set the top bit of this digit if ( X > 0 ) digit = digit OR 0x80 endif 'output' digit while ( X > 0 )
ここで、MOD はモジュロ演算子 (C では %)、DIV は整数の除法 (C では /)、そして OR はビット単位の or 演算子 (C では |) を表します。
「残りの長さ」フィールドをデコードするためのアルゴリズムは、以下のとおりです。
multiplier = 1 value = 0 do digit = 'next digit from stream' value += (digit AND 127) * multiplier; multiplier *= 128; while ((digit AND 128) != 0);
ここで、AND はビット単位の and 演算子 (C では &) を表します。
このアルゴリズムが終了すると、value には、バイト単位の残りの長さが入れられます。
残りの長さのエンコードは、変数ヘッダーの一部ではありません。 残りの長さをエンコードするときに使用されるバイト数が残りの長さの値になるわけではありません。 可変長エンコードの「延長バイト」は、変数ヘッダーの一部ではなく、固定ヘッダーの一部として考える必要があります。