Partager via


Confirmation et rejet de données sortantes

Le nœud local envoie des chaînes de données de l’hôte à l’application avec le champ ACKRQD défini comme suit :

  • Ensemble ACKRQD

    Si la requête SNA correspondante a été reçue en spécifiant une réponse définie et que les paramètres BIND spécifient que le principal utilise le mode de réponse de la chaîne d’exception/définie ou définie.

  1. ACKRQD non défini, mode de réponse

    Si la requête SNA correspondante a été reçue en spécifiant une réponse d’exception et que les paramètres BIND spécifient que le principal utilise le mode de réponse de la chaîne d’exception/définie ou d’exception.

  2. ACKRQD non défini, mode de non réponse

    Si la requête SNA correspondante a été reçue en spécifiant aucune réponse et que les paramètres BIND spécifient que le principal utilise le mode de réponse de la chaîne sans réponse.

    Dans le cas 1, l’application doit toujours envoyer un accusé de réception comme suit :

  • Si l’application accepte les données, elle doit retourner un message Status-Acknowledge(Ack).

  • Si l’application souhaite rejeter les données, elle doit retourner un message Accuser réception de l’état (Nack-1) qui transporte les codes de détection SNA appropriés.

    Dans le cas 2, l’application doit uniquement envoyer un accusé de réception dans les cas suivants :

  • Si l’application souhaite rejeter les données, elle doit retourner un message Accuser réception de l’état (Nack-1) qui transporte les codes de détection SNA appropriés.

  • L’application peut envoyer un accusé de réception de politesse à un message Exception de requête (RQE) pour effacer les données de corrélation dans le nœud local. (Pour plus d’informations, consultez Données sortantes.)

    Dans le cas 3, l’application ne doit pas envoyer d’accusés de réception. Toutefois, l’envoi d’un Status-Acknowledge(Ack) ou Status-Acknowledge(Nack-1) par l’application n’a aucun effet. Il est ignoré.

    Chaque fois qu’une application envoie un Status-Acknowledge(Ack) ou Status-Acknowledge(Nack-1) à un message Données reçu, elle confirme implicitement la réception de cela et de tous les messages de données précédemment reçus.

    Dans le cas 2, l’hôte peut émettre une requête CHASE. Le nœud local envoie une Requête Status-Control(CHASE) avec ACKRQD défini sur l’application. Lorsque l’application est en position de confirmer la réception de toutes les données en attente, elle doit émettre un message Status-Control(CHASE) Acknowledge, que le nœud local convertit en réponse positive de CHASE de l’hôte.

    Dans les cas 1 et 2, si le nœud local détecte une erreur dans une requête reçue, il convertit la requête en un message Données spécial, qu’il transmet à l’application. Quel que soit le mode de réponse de chaîne spécifié pour le secondaire dans les paramètres BIND, ce message Données présente les caractéristiques suivantes :

  • ACKRQD est défini. L’application doit confirmer la réception à l’aide d’un message Status-Acknowledge (Ack).

  • L’indicateur d’application de l’indicateur de données de direction (SDI) est défini pour indiquer qu’il s’agit d’un message de données spécial utilisé pour informer l’application d’une erreur détectée par le nœud local.

  • L’application ECI (Indicateur de chaîne de terminaison) est défini pour indiquer que la chaîne reçue est maintenant terminée.

  • Les quatre premiers octets de l’élément buffer contiennent les codes de direction SNA détectés par le nœud local à l’origine de l’arrêt.

    Ce mécanisme permet :

  • L’application qui rejette tous les messages Données précédemment reçus.

  • Le nœud local pour informer l’application des erreurs qu’il détecte dans les requêtes reçues.

  • Le nœud local pour envoyer des réponses négatives dans le bon ordre.

    Les trois figures suivantes illustrent les protocoles de confirmation et de rejet des données sortantes entre le nœud local et l’application et la façon dont ces protocoles sont liés aux protocoles SNA sous-jacents.

    Dans la première figure, l’hôte envoie une chaîne de réponse définie pour obtenir la confirmation de la réception de la requête RQR par l’application et de toutes les chaînes RQE précédemment envoyées.

    Image montrant comment un hôte envoie une chaîne de réponse définie.
    L’hôte envoie une chaîne de réponse définie

    Dans l’illustration suivante, Status-Acknowledge(Nack-1) de l’application rejette la dernière chaîne et confirme la réception de toutes les chaînes de données précédemment envoyées.

    Image montrant comment Status-Recognize(Nack-1) rejette la dernière chaîne et confirme la réception.
    Status-Acknowledge(Nack-1) rejette la dernière chaîne et confirme la réception

    Dans l’illustration suivante, l’hôte envoie une requête CHASE pour obtenir la confirmation de la réception de CHASE et de toutes les chaînes précédemment envoyées par l’application.

    Image montrant comment un hôte envoie une requête CHASE.
    L’hôte envoie une requête CHASE

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