アプリケーションがセッション間のトランザクション処理シーケンス番号を維持するために、伝送サービス・プロファイル (TS プロファイル) 4 を使用するセッションでは、セット・シーケンス番号およびテスト・シーケンス番号 (STSN) が使用されます。 これにより、セッション上の両方のパートナーが CLEAR または UNBIND-BIND シーケンスの後に失われたデータの量を検出できます。
STSN メッセージは、このようなトランザクション処理シーケンス番号をリセットできる唯一のメッセージです。 BIND、 UNBIND、 CLEAR はそれらに影響しません。
アプリケーションでこのようなトランザクション番号を保持する場合は、Open(PLU) OK 応答で APPLTRAN オプションを指定する必要があります。 ホストは、アプリケーションのトランザクション番号を設定またはテストするために SDT を送信する前に、BIND または CLEAR の後に STSN を送信できます。 ローカル・ノードは、 BIND または CLEAR を受信すると、その内部セッション・シーケンス番号をゼロにリセットします。 ローカル ノードは、1 つのハーフセッションに対して SET (または SET および TEST) を指定する STSN を受け取ると、対応する内部セッション シーケンス番号をリセットします。
両方のハーフセッション アクションが無視されない限り (アクション バイトが0x00)、 STSN 要求はアプリケーションに渡されます ( APPLTRAN が指定されている場合)。アクション バイトと要求の 2 つのシーケンス番号は Status-Control(STSN) として渡されます。 (詳細については、「 Status-Resource」を参照してください)。アプリケーションはアクション バイトを調べて、アクションが無視、設定、テスト、または設定とテストのいずれであるかを判断する必要があります。 アプリケーションは、正の応答 (Status-Control(STSN) Acknowledge) を STSN に送信し、必要に応じて検出されたシーケンス番号 (検出または設定とテスト) を行う必要があります。 ローカル ノードは、 STSN RSP の正しい結果コードを生成する役割を担います。
アプリケーションでは、最初に STSN のセンス部分を実行する必要があることに注意してください (2 次から 1 次フローのアクション バイトのビット 0 と 2 を調べて、それぞれ 1 次から 2 番目のフローを調べます)。 その後、 STSN のセット部分が実行されます (アクション バイトのビット 1 と 3 を調べることによって)。
アプリケーションは、ホストから通常のフロー要求/応答ユニット (RU) を送受信するときに、トランザクション番号をインクリメントする必要があります。 (通常のフロー データ フロー制御 (DFC) 要求に対応する 状態制御 メッセージでは、トランザクション番号がインクリメントされることに注意してください)。 シーケンス番号は、 DATAFMI メッセージと Status-Acknowledge メッセージで報告されます。 アプリケーションは、ホストからのメッセージが受信チェックに失敗した場合 (および SDI メッセージに変換された場合)、サブネットワーク アクセス プロトコル (SNAP)-2.1 がホストからチェーンの残りの部分を消去し、アプリケーションがシーケンス番号を失う可能性があることに注意する必要があります。 そのため、アプリケーションは 、SDI メッセージを処理した後、次の送信データからプライマリからセカンダリへのトランザクション番号をリセットする必要があります。
2 番目のアプリケーション フラグ バイトは Status-Control(STSN) では無効であることに注意してください。 STSN 制御バイトに使用されます。
こちらもご覧ください
アプリケーションのキャンセル
否定応答を受信した後の方向
否定応答を送信した後の方向
重大なエラー
RQR と CLEAR
リンク サービスの失敗
ローカル ノードの障害
クライアントエラー