STSN

アプリケーションがセッション間のトランザクション処理シーケンス番号を維持するために、伝送サービス・プロファイル (TS プロファイル) 4 を使用するセッションでは、セット・シーケンス番号およびテスト・シーケンス番号 (STSN) が使用されます。 これにより、セッション上の両方のパートナーは、 CLEAR または UNBIND-BIND シーケンスの後に失われたデータの量を検出できます。

STSN メッセージは、このようなトランザクション処理シーケンス番号をリセットできる唯一のメッセージです。 BIND、 UNBIND、 CLEAR はそれらに影響しません。

アプリケーションでこのようなトランザクション番号を保持する場合は、Open(PLU) OK 応答で APPLTRAN オプションを指定する必要があります。 ホストは、アプリケーションのトランザクション番号を設定またはテストするために SDT を送信する前に、BIND または CLEAR の後に STSN を送信できます。 ローカル ノードは、 BIND または CLEAR を受信すると、内部セッション シーケンス番号を 0 にリセットします。 ローカル ノードは、1 つのハーフセッションに対して SET (または SET と TEST) を指定する STSN を受け取ると、対応する内部セッション シーケンス番号をリセットします。

両方のハーフセッション アクションが無視されない限り (アクション バイトが0x00)、 STSN 要求はアプリケーションに渡されます ( APPLTRAN が指定されている場合)。アクション バイトと要求の 2 つのシーケンス番号を Status-Control(STSN) として使用します。 (詳細については、「 Status-Resource」を参照してください)。アプリケーションは、アクションバイトを調べて、アクションが無視、設定、テスト、または設定およびテストであるかどうかを判断する必要があります。 アプリケーションは、正の応答 (Status-Control(STSN) Acknowledge) を STSN に送信し、必要に応じて検出されたシーケンス番号 (センスまたは設定とテスト) を送信する必要があります。 ローカル ノードは、 STSN RSP の正しい結果コードを生成します。

アプリケーションでは、最初に STSN のセンス部分を実行する必要があることに注意してください (セカンダリからプライマリへのフローとプライマリからセカンダリ へのフローのアクション バイトのビット 0 と 2 をそれぞれ調べることで)。 その後、 STSN のセット部分が実行されます (アクション バイトのビット 1 と 3 を調べることによって)。

アプリケーションは、ホストから通常のフロー要求/応答ユニット (RU) を送受信するときに、トランザクション番号をインクリメントする必要があります。 (通常のフロー データ フロー制御 (DFC) 要求に対応する Status-Control メッセージでは、トランザクション番号がインクリメントされることに注意してください)。 シーケンス番号は、 DATAFMI メッセージと Status-Acknowledge メッセージで報告されます。 アプリケーションは、ホストからのメッセージが受信チェックに失敗した場合 (および SDI メッセージに変換されます)、サブネットワーク アクセス プロトコル (SNAP)-2.1 はホストからチェーンの残りの部分を消去し、アプリケーションがシーケンス番号を見逃す可能性があることに注意する必要があります。 そのため、アプリケーションは 、SDI メッセージを処理した後、次の送信データからプライマリからセカンダリへのトランザクション番号をリセットする必要があります。

2 番目のアプリケーション フラグ バイトは Status-Control(STSN) では無効であることに注意してください。 STSN 制御バイトに使用されます。

参照

アプリケーションの CANCEL
異常な応答の受信後の方向
異常な応答の送信後の方向
クリティカルな障害
RQR と CLEAR
リンク サービスの障害
ローカル ノードの障害
クライアント エラー