Confirmation et rejet de données entrantes

Pour chaque chaîne SNA de données envoyée ou reçue pour laquelle des réponses sont en suspens, comme Request Exception (RQE) ou Definite Response Required (RQD), le nœud local gère une entrée de table de corrélation. Si les entrées de la table sont épuisées, le nœud local met fin à la session en utilisant le plus grand nombre d’entrées de table possible. Un message Status-Error (code 0x46) et une requête Close(PLU) sont envoyés à l’application, et un message TERM-SELF est envoyé à l’hôte. Les pénuries d’entrée de table (entrantes) peuvent être évitées par l’envoi de données de sens de modification (CD) (pour le semi-duplex), d’ACKRQD de données ou de n’importe quel message Status-Control(CHASE) ou Status-Control(LUSTAT) avec ACKRQD. Les pénuries sortantes peuvent être évitées en envoyant des messages d’accusé de réception comme décrit dans Ouverture de la connexion PLU.

Le nœud local envoie des chaînes de données à l’hôte avec le mode de réponse de chaîne spécifié comme suit :

1. Définie

   Si l’application envoie un message Data au nœud local avec l’ensemble de champs ACKRQD, et que les paramètres de BIND spécifient que le réplica secondaire utilise le mode de réponse définie ou définie/exception.

2. Exception

   Si l’application envoie un message Data au nœud local sans l’ensemble de champs ACKRQD, et que les paramètres de BIND spécifient que le réplica secondaire utilise le mode de réponse exception ou défini/exception.

3. Aucune réponse

   Si l’application envoie un message Data au nœud local sans l’ensemble de champs ACKRQD, et que les paramètres de BIND spécifient que le réplica secondaire utilise le mode sans réponse.

   Si le paramètre ACKRQD sur un message Data de l’application ne reflète pas le mode de réponse de chaîne spécifié dans les paramètres de BIND, le nœud local retourne Status-Acknowledge(Nack-2), indiquant un code d’erreur non critique. Par exemple, si l’application spécifie ACKRQD, mais que les paramètres de BIND n’autorisent pas le nœud local à envoyer des chaînes de réponse définies.

   Dans le cas 1, l’application reçoit un accusé de réception pour toutes les chaînes de données de gestion des fonctions qu’elle envoie au nœud local :

• Les réponses positives de l’hôte sont retournées à l’application sous forme de messages Status-Acknowledge(Ack).

• Les réponses négatives de l’hôte sont retournées en tant que messages Status-Acknowledge(Nack-1) qui transportent les codes de détection SNA.

• Les erreurs détectées par le nœud local lors de la tentative d’envoi du message sont retournées en tant que messages Status-Acknowledge(Nack-2) portant le code d’erreur équivalent.

  Dans le cas 2, l’application reçoit uniquement un accusé de réception d’une chaîne FMD qu’elle envoie au nœud local pour :

• Les réponses négatives de l’hôte, qui sont retournées en tant que messages Status-Acknowledge(Nack-1) qui transportent les codes de détection SNA.

• Les erreurs détectées par le nœud local lors de la tentative d’envoi du message, qui sont retournées en tant que messages Status-Acknowledge(Nack-2) portant le code d’erreur équivalent.

  Dans le cas 3, l’application reçoit uniquement un accusé de réception d’une chaîne FMD qu’elle envoie au nœud local lorsque le nœud détecte une erreur dans le message et envoie à l’application Status-Acknowledge(Nack-2) . La seule chose que l’hôte peut faire est d’envoyer un 0x400A LUSTAT ultérieure (aucune réponse/non pris en charge) avec le numéro de séquence de la requête dans le champ sense qualifier. Il est présenté à l’application en tant que message Status-Control(LUSTAT) comme en temps normal.

  Chaque fois qu’une application reçoit Status-Acknowledge(Ack) ou Status-Acknowledge(Nack-1) , elle confirme implicitement la réception par la demi-session partenaire dans l’hôte de toutes les chaînes précédemment envoyées.

  Dans le cas 2, l’application ne reçoit généralement pas de telles réponses de l’hôte pour les chaînes qu’elle a envoyées, et dans le cas 3, l’application ne reçoit jamais ces réponses. Par conséquent, pour que l’hôte confirme la réception de toutes les chaînes précédemment envoyées, l’application doit émettre une requête Status-Control(CHASE) avec ACKRQD défini. Ainsi, le nœud local génère une requête SNA CHASE sur l’hôte. La réception de la réponse à cette requête CHASE confirme que l’hôte a reçu cette requête CHASE et toutes les chaînes précédentes envoyées par l’application. Le nœud local émet Status-Control(CHASE) Acknowledge pour informer l’application que c’est le cas.

  Les trois figures suivantes illustrent les protocoles de confirmation et de rejet des données entrantes 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, une application définit le champ ACKRQD dans une chaîne de données entrante pour demander à l’hôte de confirmer la réception de la chaîne et de toutes les chaînes précédemment envoyées.

  
  Une application définit le champ ACKRQD

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

  
  Status-Acknowledge(Nack-1) rejette la dernière chaîne, mais confirme la réception

  Dans l’illustration suivante, l’application utilise Status-Control(CHASE) pour demander à l’hôte de confirmer la réception de la requête CHASE correspondante et de toutes les chaînes précédemment envoyées.

  
  Utilisation de Status-Control(CHASE) pour demander à l’hôte de confirmer la réception de la requête CHASE correspondante

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