Hitachi

OpenTP1 Version 7　分散トランザクション処理機能　OpenTP1 プロトコル TP1/NET/TCP/IP編

2.3.7　メッセージの分割と組み立て

TP1/NET/TCP/IPがメッセージを受け取る場合，相手システムから送信されたメッセージがネットワーク内で分割されたり，前後に送信されたメッセージと結合してしまうことがあります。また，メッセージを受け取る側のシステムでは，送信されたメッセージのセグメントがどこまでで終わっているのかを正確に認識できません。ただし，メッセージの送信順序は保証されます。

分割，または結合されたメッセージは，受け取る側のシステムが再度分割，組み立てをすることで，正常な論理メッセージとなります。メッセージの分割，および組み立て時には，該当するメッセージが論理メッセージのセグメントの終わりかどうかを判定する必要があります。TP1/NET/TCP/IPでは，受信メッセージ組み立て機能，または入力セグメント判定UOCで入力セグメントの終わりを判定し，メッセージの分割・組み立てをします。受信メッセージ組み立て機能，または入力セグメント判定UOCを使用しない場合は，TP1/NET/TCP/IPはTCP/IPソケットの受信バッファから受け取ったメッセージをそのままUAPに通知します。この場合，UAPでメッセージの分割・組み立てを行ってください。

〈この項の構成〉

(1)　受信メッセージの組み立て機能

コネクション定義（mcftalccn -u）のmasmオペランドにyesを指定した場合，受信メッセージの組み立て機能を使用できます。

受信メッセージ組み立て機能を使用する場合，メッセージ送信時に，TP1/NET/TCP/IPはメッセージ中の先頭に自動的にメッセージ長エリアを付けます。そのエリアにバイト順序がビッグエンディアン※の整数型のメッセージ長を設定し，特定のフォーマットにして送信します。このとき，メッセージが分割されるかどうかは，システム（ソケット）の送受信バッファ長に依存します。

メッセージ受信時には，メッセージ中に設定したメッセージ長エリアのバイト順序がビッグエンディアンの整数型であることを前提に論理メッセージを組み立てます。このため，相手システムはメッセージ長エリアにバイト順序がビッグエンディアンの整数型のメッセージ長を設定する必要があります。

注※

ビッグエンディアンとはバイトを低い方から順番に並べて，最下位のビットを最上位のバイトに置く方式のことです。

[図データ]

メッセージ受信時，メッセージ中のTP1/NET/TCP/IPが送信時に付けたメッセージ長エリアを自動的に削除します。受信メッセージ組み立て機能での分割・組み立ての概要を次の図に示します。

図2‒45　受信メッセージ組み立て機能での分割・組み立て

[図データ]
（凡例）

L1，L2：メッセージ長

メッセージ長エリアにバッファグループ定義（mcftbuf -g）のlengthオペランドで定義した受信バッファのサイズを超える値が設定されていた場合，TP1/NET/TCP/IPは受信バッファオーバフローと見なし，コネクションを解放します。

ページの先頭へ

(2)　入力セグメント判定UOC

入力セグメント判定UOCは，TP1/NET/TCP/IPが蓄積している受信メッセージがセグメントとして完成しているかどうか，完成している場合は，完成したセグメントと後続のセグメントとの境界がどこであるかを判断するためのUOCです。

入力セグメント判定UOCを使用する場合，セグメントの終わりを判定するための目印が必要となります。例えば，メッセージにメッセージ長を含んだヘッダを付けることによって，入力セグメント判定UOCで，セグメントの終わりを判定できます。

送信されたメッセージが後続のメッセージと結合している場合は，該当するメッセージのセグメントの終わりを判定すると同時に，次のメッセージの長さを計算します。メッセージの形式は，システム間であらかじめ取り決めておきます。

入力セグメント判定UOCでの分割・組み立てを次の図に示します。

図2‒46　入力セグメント判定UOCでの分割・組み立て

[図データ]

入力セグメント判定UOCがセグメント未完を指示したとき，UOCに渡したメッセージのサイズと該当メッセージの残りのサイズの和がバッファグループ定義で定義した受信バッファのサイズを超えている場合，TP1/NET/TCP/IPは受信バッファオーバフローと見なし，コネクションを解放します。

入力セグメント判定UOCの詳細については，「5.1.1　入力セグメントの判定」を参照してください。

ページの先頭へ

(3)　受信バッファの空き待ち

論理メッセージの組み立てと論理メッセージの入力キューへの格納は，非同期に行われます。

TCP/IPソケットの受信バッファから受け取ったメッセージは，入力キューに格納するまでコネクション定義（mcftalccn -g）のrcvbufオペランドで指定した受信バッファに保持されます。

相手システムから一方的に連続してメッセージを受信するなどによって受信バッファの空きが不足した場合，TP1/NET/TCP/IPは受信バッファの空きを最大3分間待ち合わせます。受信バッファの空きを待ち合わせている間は，相手システムからメッセージを受信したり，相手システムからのコネクション解放を検出できなくなります。一定時間が経過したあとも受信バッファの空きがない場合は，メッセージログ（KFCA14847-E）を出力し，コネクションを解放します。

入力キューへの格納が完了するなどによって，TP1/NET/TCP/IPが受信バッファの空きを検出すると，再び相手システムからメッセージを受信したり，相手システムからのコネクション解放を検出できるようになります。なお，受信バッファの空きチェックはタイマ定義（mcfttim -b）のbtimオペランドの指定値の間隔で行います。

受信バッファの空き待ちを次の図に示します。

図2‒47　受信バッファの空き待ち

[図データ]

  1. 相手システムからメッセージを受信します。

  2. 1.で受信したメッセージを入力キューに格納する前に相手システムからメッセージを受信します。

  3. 受信バッファ不足を検出すると，メッセージログ（KFCA14877-I）を出力し，受信バッファの空きを待ち合わせます。

  4. 1.で受信したメッセージを入力キューに格納すると，受信バッファの空きを検出します。

  5. 2.で受信したメッセージを入力キューに格納します。

受信バッファの空き待ちによって受信処理が遅延し，性能に影響を与えるおそれがあるため，受信バッファ面数には余裕を持った値を見積もってください。詳細については，「6.　システム定義」の「mcftalccn（コネクション定義の開始）」の注意事項を参照してください。

ページの先頭へ

商品名称に関する表示

All Rights Reserved. Copyright (C) 2006, 2021, Hitachi, Ltd.