STSN

Les numéros de séquence de jeu et de test (STSN) sont utilisés sur les sessions avec le profil TS (Transmission Service Profile) 4 pour que les applications conservent les numéros de séquence de traitement des transactions 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 des transactions. 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 OPEN(PLU) OK. L’hôte peut envoyer STSN après une liaison 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 lors de 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.

Sauf si les deux actions de demi-session sont ignorées (l’octet d’action est 0x00), la requête STSN est transmise à l’application (à condition qu’elle spécifie APPLTRAN), avec l’octet d’action et les deux numéros de séquence de la requête, en tant que stSN (Status-Control(STSN) . (Pour plus d’informations, consultez Status-Resource.) L’application doit examiner l’octet d’action pour déterminer si l’action est ignorée, définie, test ou définie et test. L’application doit envoyer une réponse positive (Status-Control(STSN) Accusé de réception) au STSN, avec les numéros de séquence détectés si nécessaire (sens ou définition et test). Le nœud local est chargé de générer le code de résultat correct pour le RSP STSN.

Notez que l’application doit d’abord effectuer la partie logique du STSN (en examinant respectivement les bits 0 et 2 de l’octet d’action pour le flux secondaire à principal et le flux principal à secondaire). 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 requête/réponse de flux normales à partir de l’hôte. (Notez que les messages Status-Control correspondant aux requêtes 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 Status-Acknowledge . L’application doit savoir que, si un message de l’hôte échoue, reçoit des vérifications (et est converti en message SDI ), le protocole d’accès au sous-réseau (SNAP)-2.1 purge 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

ANNULATION de l’application
Direction après réception d’une réponse négative
Direction après l’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