STSN

Les numéros de séquence de jeu et de test (STSN) sont utilisés sur les sessions avec le profil de service de transmission (profil TS) 4 pour permettre aux applications de gérer les numéros de séquence de traitement transactionnel entre les sessions. Cela permet aux deux partenaires de la session de découvrir la quantité de données perdues après une séquence CLEAR ou UNBIND-BIND .

Le message STSN est le seul qui peut réinitialiser ces numéros de séquence de traitement de transaction. BIND, UNBIND et CLEAR ne les affectent pas.

Si l’application souhaite conserver ces numéros de transaction, elle doit spécifier l’option APPLTRAN dans la réponse OK Open(PLU). L’hôte peut envoyer STSN après un bind ou clear avant d’envoyer SDT pour définir ou tester les numéros de transaction de l’application. Le nœud local réinitialise ses numéros de séquence de session interne à zéro à la réception de BIND ou CLEAR. Lorsque le nœud local reçoit un STSN spécifiant SET (ou SET et TEST) pour une demi-session, il réinitialise le numéro de séquence de session interne correspondant.

À moins que les deux actions demi-session ne soient ignorées (l’octet d’action est 0x00), la requête STSN est transmise à l’application (à condition qu’elle ait spécifié APPLTRAN), avec l’octet d’action et les deux numéros de séquence de la demande, en tant que contrôle d’état (STSN). (Pour plus d’informations, consultez Status-Resource.) L’application doit examiner l’octet d’action pour déterminer si l’action est ignorer, définir, tester ou définir et tester. L’application doit envoyer une réponse positive (Status-Control (STSN) Acknowledge) au STSN, avec les numéros de séquence détectés si nécessaire (sens ou set et test). Le nœud local est responsable de la génération du code de résultat correct pour le RSP STSN.

Notez que l’application doit d’abord effectuer la partie sense de STSN (en examinant les bits 0 et 2 de l’octet d’action pour le flux secondaire à principal et le flux de principal à secondaire respectivement). La partie définie du STSN est ensuite effectuée (en examinant les bits 1 et 3 de l’octet d’action).

L’application doit incrémenter ses numéros de transaction lors de l’envoi et de la réception d’unités de demande/réponse de flux normal (RU) à partir de l’hôte. (Notez que les messages de contrôle d’état correspondant aux demandes de contrôle de flux de données de flux normal (DFC) entraînent l’incrémentation des numéros de transaction.) Le numéro de séquence est signalé sur les messages DATAFMI et les messages d’accusé de réception d’état . L’application doit savoir que, si un message de l’hôte échoue à recevoir des vérifications (et est converti en message SDI ), le protocole d’accès au sous-réseau (SNAP)-2.1 vide le reste de la chaîne de l’hôte et l’application peut manquer certains numéros de séquence. Par conséquent, l’application doit réinitialiser son numéro de transaction primaire à secondaire à partir des données sortantes suivantes après le traitement d’un message SDI .

Notez que le deuxième octet d’indicateur d’application n’est pas valide pour Status-Control(STSN). Il est utilisé pour l’octet de contrôle STSN .

Voir aussi

CANCEL généré par une application
Redirection après réception d’une réponse négative
Redirection après envoi d’une réponse négative
Échec critique
RQR et CLEAR
Échec du service de liaison
Échec du nœud local
Échec du client