Partager via

Shutdown

  • Article

Le protocole d’arrêt permet à l’application hôte d’empêcher l’application d’envoyer d’autres requêtes de flux normales. Ce protocole est utilisé lorsque l’application hôte souhaite mettre fin à la session de façon ordonnée et n’est disponible que pour les sessions utilisant le profil de gestion des fonctions (FM) 3 ou 4.

Si le nœud local reçoit une requête SHUTD de la part de l’hôte, il émet une requête Status-Control(SHUTD) (sans ACKRQD) pour demander à l’application d’entrer dans un état de veille à un moment opportun. L’application détermine ce qui convient le mieux. Par exemple, cela peut être postérieur à la réception d’un message Status-Session(BETB) .

Lorsque l’application décide qu’elle est prête à s’arrêter, elle doit émettre une requête Status-Control(SHUTC) (à nouveau sans ACKRQD) pour indiquer cette transition. Le nœud local informe l’hôte de cette modification en envoyant une requête SHUTC. L’hôte peut continuer à envoyer des requêtes sortantes de flux normal et peut ensuite effectuer une des actions suivantes :

  • L’hôte met fin à la session d’unité logique principale (PLU) en envoyant une requête BIND. Le nœud local ferme la connexion PLU en envoyant une requête Close(PLU) à l’application. La session du point de contrôle des services système (SSCP) reste active.

  • L’hôte abandonne la procédure d’arrêt en envoyant une requête RELQ. Le nœud local envoie une requête Status-Control(RELQ) (avec ACKRQD) à l’application pour indiquer qu’il peut à présent reprendre l’envoi sur la session PLU. RELQ est uniquement pris en charge sur les sessions utilisant le profil FM 4.

  • L’hôte réinitialise la session en envoyant CLEAR, un profil de service de transmission (profil TS) 3 ou 4. Un des effets de cette action est la levée de l’état suspendu. (Pour plus d’informations, voir Récupération.)

    Les deux figures suivantes illustrent les protocoles d’arrêt entre le nœud local et l’application et la façon dont ces protocoles sont liés aux protocoles SNA sous-jacents.

    Dans l’illustration suivante, l’hôte envoie SHUTD pendant que l’application envoie l’état dans le crochet. L’application termine le crochet, envoie la requête Status-Control(SHUTC) , et l’hôte arrête la session PLU en envoyant UNBIND. Le nœud local ferme la connexion PLU.

    Image montrant comment un hôte envoie SHUTD pendant que l’application envoie l’état entre crochets.
    L’hôte envoie SHUTD pendant que l’application envoie l’état dans le crochet

    Dans l’illustration suivante, l’hôte envoie SHUTD pendant que l’application envoie l’état dans le crochet. L’application termine le crochet, envoie la requête Status-Control(SHUTC) , puis l’hôte libère l’application de l’état suspendu en envoyant RELQ. Le nœud local envoie une requête Status-Control(RELQ) à l’application, qui initie un nouveau crochet.

    Image montrant un hôte qui envoie SHUTD pendant que l’application envoie l’état entre crochets.
    L’hôte envoie SHUTD pendant que l’application envoie l’état dans le crochet

Voir aussi

Ouverture de la connexion PLU
Session PLU
Chaînage sortant
Chaînage entrant
Livraison de segment
Brackets
Sens
Rythme et segmentation
Confirmation et rejet des données]
Arrêt et mise en suspens
Récupération
Terminaison initié par l’application
LUSTATs]
Données de la surveillance des temps de réponse