STSN

Set- und Testsequenznummern (STSN) werden für Sitzungen mit dem Übertragungsdienstprofil (TS-Profil) 4 für Anwendungen verwendet, um Transaktionsverarbeitungssequenznummern zwischen Sitzungen beizubehalten. Dadurch können beide Partner in der Sitzung ermitteln, wie viele Daten nach einer CLEAR - oder UNBIND-BIND-Sequenz verloren gehen.

Die STSN-Nachricht ist die einzige Nachricht, die solche Transaktionsverarbeitungssequenznummern zurücksetzen kann. BIND, UNBIND und CLEAR wirken sich nicht darauf aus.

Wenn die Anwendung solche Transaktionsnummern beibehalten möchte, muss sie die APPLTRAN-Option in der Open(PLU) OK-Antwort angeben. Der Host kann STSN nach einem BIND oder CLEAR senden, bevor er SDT sendet, um die Transaktionsnummern der Anwendung festzulegen oder zu testen. Der lokale Knoten setzt seine internen Sitzungssequenznummern nach Erhalt von BIND oder CLEAR auf 0 zurück. Wenn der lokale Knoten einen STSN empfängt, der SET (oder SET und TEST) für eine halbe Sitzung angibt, wird die entsprechende interne Sitzungssequenznummer zurückgesetzt.

Sofern nicht beide Halbsitzungsaktionen ignoriert werden (das Aktionsbyte ist 0x00), wird die STSN-Anforderung an die Anwendung übergeben (vorausgesetzt, sie hat APPLTRAN angegeben) mit dem Aktionsbyte und den beiden Sequenznummern aus der Anforderung als Status-Control(STSN). (Weitere Informationen finden Sie unter Status-Ressource.) Die Anwendung muss das Aktionsbyte untersuchen, um festzustellen, ob die Aktion ignoriert, festgelegt, getestet oder festgelegt und getestet wird. Die Anwendung muss eine positive Antwort (Status-Control(STSN) Acknowledge) an die STSN senden, bei Bedarf mit den erkannten Sequenznummern (Sense oder Set und Test). Der lokale Knoten ist für die Generierung des richtigen Ergebniscodes für den STSN-RSP verantwortlich.

Beachten Sie, dass die Anwendung zuerst den Sense-Teil von STSN ausführen sollte (durch Untersuchung der Bits 0 und 2 des Aktionsbytes für den Sekundär-zu-Primär-Fluss bzw. primär-zu-sekundären Fluss). Der festgelegte Teil der STSN wird dann ausgeführt (durch Untersuchung der Bits 1 und 3 des Aktionsbytes).

Die Anwendung sollte ihre Transaktionsnummern erhöhen, wenn normale Flussanforderungen/Antworteinheiten (RUs) vom Host gesendet und empfangen werden. (Beachten Sie, dass Status-Control-Nachrichten , die normalen DFC-Anforderungen (Flow Data Flow Control) entsprechen, dazu führen, dass die Transaktionsnummern inkrementiert werden.) Die Sequenznummer wird für DATAFMI-Nachrichten und Statusbestätigungsmeldungen gemeldet. Die Anwendung sollte sich darüber im Klaren sein, dass, wenn eine Nachricht vom Host fehlschlägt, die Empfangsüberprüfungen (und in eine SDI-Nachricht konvertiert wird), snap-2.1 (Sub-Network Access Protocol) den Rest der Kette vom Host löscht, und die Anwendung kann einige Sequenznummern verpassen. Daher sollte die Anwendung nach der Verarbeitung einer SDI-Nachricht ihre primäre zu sekundäre Transaktionsnummer von den nächsten ausgehenden Daten zurücksetzen.

Beachten Sie, dass das zweite Anwendungsflagging-Byte für Status-Control(STSN) ungültig ist. Es wird für das STSN-Steuerelementbyte verwendet.

Weitere Informationen

Anwendung: CANCEL
Richtung nach dem Empfangen einer negativen Antwort
Richtung nach dem Senden einer negativen Antwort
Kritischer Fehler
RQR und CLEAR
Fehler bei einem Linkdienst
Fehler bei einem lokalen Knoten
Clientfehler