Segmentation
La segmentation peut être considérée comme similaire à la segmentation. (Pour plus d’informations, consultez Livraison de segments.) La distinction est que la segmentation est déterminée par le lien de communication entre le nœud local et le système distant, tandis que la segmentation est déterminée par le lien de communication entre l’application et le nœud local.
L’application indique sur la requête Open(SSCP) si elle prend en charge la segmentation et, si c’est le cas, la taille de bloc en octets qu’elle souhaite utiliser. Le nœud local utilise ensuite la taille de l’unité de requête/réponse (RU), la taille de bloc et la taille de segment (le cas échéant) pour déterminer si la segmentation est nécessaire. Il spécifie ensuite les tailles de bloc utilisées pour le flux entrant et sortant (qui ne doivent pas nécessairement être identiques) sur la requête Open(PLU). Ces valeurs sont spécifiées en unités d’éléments. (Pour plus d’informations, consultez Messages.) La valeur zéro pour l’une ou l’autre de ces tailles indique que la segmentation n’est pas nécessaire, car la taille de bloc n’est pas le facteur de limitation. Notez que lors de la segmentation des données, une UNITÉ de requête n’est pas fractionnée au milieu d’un élément. Cela évite la copie de données.
Par exemple, supposons que le nœud local utilise une taille de RU de 8 kilo-octets (Ko) et des segments de 2 Ko, et que la requête Open(SSCP) de l’application spécifie la remise de segment et une taille de bloc de 4 Ko. La segmentation sera utilisée sur le flux de données entrantes (car la taille du bloc est inférieure à la taille de la RU), mais n’est pas nécessaire sur le flux de données sortant (car les données seront remises dans des segments inférieurs à la taille du bloc).
Si la segmentation est utilisée dans l’une ou l’autre direction, toutes les valeurs de crédit spécifient le nombre de blocs qui peuvent être envoyés dans cette direction, et non le nombre d’unités de requête. Notez que l’option de remise de segment est incluse dans la requête Open(SSCP) pour permettre au nœud local de calculer les valeurs de crédit de bloc initial sur la connexion PLU correspondante. L’application doit également définir cette option sur la réponse Open(PLU). Si la requête Open(SSCP) et la réponse Open(PLU) ont des paramètres différents de cette option, le paramètre de la réponse Open(PLU) est utilisé. Cela peut signifier que la valeur de crédit initiale utilisée n’est pas appropriée.
Si le rythme au niveau de la session est utilisé, le nœud local le lie au crédit de segmentation. En particulier, si l’application retient le crédit, le nœud local retarde l’envoi d’une réponse de rythme à l’hôte, appliquant ainsi une pression différée à l’hôte. Cette liaison est gérée par le nœud local et ne doit pas nécessairement concerner l’application.
Les indicateurs d’application sur des blocs d’unités de requête sont gérés de la même façon que ceux des segments. (Pour plus d’informations, consultez Indicateurs d’application et remise de segments.) En particulier :
FMHI, BCI, COMMIT, BBI, EBI, CODE, ENCRYP, ENPAD, QRI et CEI ne sont définis que sur le premier segment d’une UNITÉ de requête.
ECI et CDI ne sont définis que sur le dernier bloc d’une UNITÉ de requête.
BBIUI est toujours défini sur le premier bloc d’une RU.
EBIUI est toujours défini sur le dernier bloc d’une unité de requête.
Notez que L’EBI est défini sur le premier bloc de la dernière RU entre crochets et non sur le dernier bloc comme on peut s’y attendre. Il s’agit du même comportement que pour la remise de segments. L’application doit utiliser le message Status-Session (BETB), et non l’indicateur EBI, pour déterminer quand un crochet est terminé.
Les blocs sont identifiés à l’aide des indicateurs de segmentation BBIUI et EBIUI. Par conséquent, l’application ne peut pas faire la distinction entre les segments et les segments si la segmentation et la segmentation sont utilisées en sortie. Toutefois, la distinction n’est généralement pas nécessaire. L’application peut effectuer l’ombrage des fenêtres en affichant chaque unité de données à mesure qu’elles sont reçues, que l’unité de données soit un segment ou un bloc. (Pour plus d’informations, consultez Livraison de segments.)
Notes
Les versions précédentes de ce document l’indiquaient comme une fonctionnalité future. La prise en charge est activée dans Host Integration Server. Les applications peuvent tester la version du produit retournée lors d’un appel à sepdgetinfo pour la version 1.2 ou ultérieure avant d’utiliser le système de segmentation.
Dans certains cas, la taille de ru utilisée par le nœud local peut être trop grande pour la longueur du chemin entre le nœud local et une application FMI, par exemple, lors de l’utilisation d’une liaison en anneau de jetons de 16 mégaoctets (Mo), qui peut prendre en charge des trames de 16 kilo-octets (Ko). Le nœud local permet à une application FMI de spécifier que le transfert de données doit se faire en unités plus petites, appelées blocs.
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