Rythme sortant

Si l’application dispose de suffisamment de ressources pour gérer des données sortantes aussi rapidement que le réseau peut les fournir (par exemple, un écran), ou si un protocole de niveau supérieur (par exemple, le mode de requête immédiate) limite le trafic de données, l’application n’a pas besoin d’être impliquée dans le rythme et il est possible que le nœud local gère le rythme sortant de façon transparente.

Toutefois, certains types d’applications peuvent nécessiter une implication dans le rythme de trafic sortant. Si l’application dispose de ressources limitées (par exemple, une imprimante), l’application doit spécifier l’option de rythme des applications dans le bloc de contrôle d’informations de connexion (CICB) de la réponse Open(PLU) OK. (Pour plus d’informations, consultez Ouverture de la connexion PLU.) L’application doit également fournir le nœud local avec des informations sur l’état de ces ressources initialement sur la réponse Open(PLU) OK et à l’aide de messages de ressource d’État.

Pour aider l’application à calculer le champ de crédit initial dans la réponse Open(PLU) OK, le nœud local remet les tailles de fenêtre de rythme et les tailles d’unités de requête/réponse maximales (RU) primaires et secondaires sur la requête Open(PLU). Le crédit initial doit être au moins aussi grand que la taille de la fenêtre primaire à secondaire. Dans le cas contraire, la requête BIND est rejetée et l’application reçoit un message Open(PLU) Error Confirm. Le nœud local remplit une valeur de crédit initiale suggérée d’une valeur supérieure à celle de la fenêtre de rythme (pour essayer d’éviter les situations d’arrêt au démarrage).

Notez que le nœud local rejettera également la requête BIND si l’application spécifie qu’elle doit être impliquée dans un rythme (quel que soit le crédit initial), mais que la requête BIND spécifie qu’il n’existe pas de rythme sortant.

Seules les requêtes de données de gestion des fonctions (FMD) font partie du schéma de crédit. L’application doit donc conserver de l’espace dans sa mémoire tampon pour 1 requête Status-Acknowledge par RU en plus du nombre de RU spécifié par le nombre initial de crédits. (Un message Status-Control occupe 36 octets.)

Chaque unité de crédit que l’application remet au nœud local permet au nœud local de fournir à l’application une seule RU (ou un seul segment si la segmentation est utilisée). Notez que si l’application reçoit des segments, cela peut correspondre à plusieurs messages DATAFMI. L’application peut compter les RU dans le cadre du contrôle de flux sortant à l’aide des indicateurs BBIU (Begin Basic Information Unit) et EBIU (End Basic Information Unit).

L’application doit conserver le nombre de crédits utilisés, qu’elle doit rapporter au nœud local dans les messages Status-Resource. L’application doit effectuer les actions suivantes :

• Lors du traitement (et non de la réception) des messages DATAFMI avec EBIU défini (correspondant aux requêtes FMD), incrémentez le nombre de crédits utilisés de 1.

• Lors du traitement des messages Status-Control et de tous les autres messages du nœud local, n’augmentez pas le nombre de crédits utilisés.

• Signale régulièrement le nombre actuel de crédits utilisés dans un message Status-Resource.

• Signale le nombre de crédits utilisés lorsque sa mémoire tampon devient vide (quel que soit le dernier message traité), à moins que le nombre de crédits utilisés ne soit égal à zéro.

• Lorsque le nombre de crédits utilisés est rapporté au nœud local, réinitialisez-le à zéro.

  La fréquence à laquelle l’application fournit des messages Status-Resource n’est pas structurée. Toutefois, le nœud local envoie uniquement à l’application le nombre de messages Data possible avec les crédits qu’il a reçus. Lorsque le nombre de crédits utilisés de l’application atteint la valeur de crédit initiale, le nœud local n’envoie plus de données. L’application doit tenter d’envoyer un message Status-Resource avant que cela se produise, car si le nœud local ne peut pas envoyer de message Data à l’application et que l’hôte continue à envoyer des requêtes, le nœud local peut ne pas être en mesure d’envoyer une réponse de rythme à l’hôte quand cela est nécessaire, causant ainsi une dégradation des performances.

  Si la fenêtre de rythme est petite, par exemple 1 ou 2, l’application doit envoyer un message Status-Resource après le traitement de chaque message DATAFMI pour permettre au nœud local d’envoyer la réponse de rythme appropriée.

  La figure suivante illustre la gestion du rythme de sortie par le nœud local quand l’application n’est pas impliquée (APPLPAC = 0x00). La fenêtre de rythme est supposée être de deux.

  
  Nœud local gérant un rythme de sortie

  L’illustration suivante montre le nœud local et l’application gérant le rythme de sortie avec une fenêtre de rythme de sortie supposée être de deux et un crédit initial du nœud local à l’application supposé être de quatre. Notez que le nœud local peut envoyer une réponse de rythme isolée à l’hôte pour obtenir une autre fenêtre remplie de données dès que l’application a un crédit suffisant pour le reste de la fenêtre actuelle et la fenêtre suivante.

  
  Un nœud local et une application gérant le rythme de sortie

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