RQR et CLEAR

Une application utilisant le profil de service de transmission (profil TS) 4 peut demander la récupération de la session en envoyant Status-Control(RQR) . Le nœud local la présente à l’hôte en tant que requête RQR. Notez que si l’application a reçu un Status-Acknowledge(Nack-2) critique, cette option ne peut pas être prise, car le nœud local envoie une requête Close(PLU) immédiatement aprèsStatus-Acknowledge(Nack-2) à l’application, et la connexion d’unité logique principale (PLU) n’est plus valide. Le message RQR demande à l’hôte de réinitialiser la session en envoyant une requête CLEAR, comme illustré dans la figure suivante.

La réception de CLEAR entraîne la réinitialisation de l’état de session de l’application à la suite de BIND, Open(PLU) .

Une autre façon pour l’application de traiter les conditions d’erreur consiste à demander UNBIND en envoyant Status-Control(RSHUTD) . (Pour plus d’informations, consultez Arrêt initié par l’application.) Notez que cela peut ne pas obliger l’hôte à fournir une nouvelle requête BIND, en fonction de la configuration de l’hôte. Une nouvelle requête SSCP peut être requise (par exemple, LOGON).

Dans l’illustration suivante, l’application demande la récupération en émettant Status-Control(RQR) . L’hôte envoie CLEAR, et l’application doit réinitialiser sa session pour indiquer qu’elle suivait la requête BIND(Open(PLU)) . Dans ce cas, l’application se trouve maintenant entre crochets et en attente du trafic de données de démarrage (SDT).

L’application demande la récupération en émettant Status-Control(RQR)

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
STSN
Échec du service de liaison
Échec du nœud local
Échec du client