Partager via


Chunking

Le découpage peut être considéré comme similaire à la segmentation. (Pour plus d’informations, consultez Segment Delivery.) 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 le découpage est déterminé 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, le cas échéant, 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 du bloc et la taille du 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 n’ont pas besoin d’ê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 du bloc n’est pas le facteur de limitation. Notez que dans les données de segmentation, une RU ne sera pas fractionnée au milieu d’un élément. Cela évite la copie des 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 des segments et une taille de segment de 4 Ko. La segmentation est utilisée sur le flux de données entrant (car la taille du bloc est inférieure à la taille de ru), mais n’est pas nécessaire sur le flux de données sortant (car les données sont livrées dans des segments inférieurs à la taille de 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 morceaux 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 demande Open(SSCP) pour permettre au nœud local de calculer les valeurs de crédit de bloc initiales sur la connexion PLU correspondante. L’application doit également définir cette option sur la réponse Open(PLU). Si la demande 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, exerçant ainsi une pression de retour sur l’hôte. Cette liaison est gérée par le nœud local et n’a pas besoin de concerner l’application.

Les indicateurs d’application sur les 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 Livraison 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 RU.

  • ECI et CDI sont uniquement définis sur le dernier segment d'une RU.

  • BBIUI est toujours défini sur le premier segment d’une RU.

  • EBIUI est toujours appliqué au dernier segment d'une RU.

    Notez que l’EBI est définie sur le premier bloc du dernier RU entre crochets et non sur le dernier segment, comme prévu. Il s’agit du même comportement que pour la distribution de segments. L’application doit utiliser le message Status-Session(BETB), et non l’indicateur EBI, pour déterminer quand un crochet s’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 blocs et les segments si la segmentation et le découpage sont utilisés en sortie. Toutefois, il n’est généralement pas nécessaire de faire la distinction. L’application peut effectuer un ombrage de fenêtre en affichant chaque unité de données telle qu’elle est reçue, que l’unité de données soit un segment ou un bloc. (Pour plus d’informations, consultez Segment Delivery.)

Remarque

Les versions précédentes de ce document l’ont indiqué 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 de jeton de 16 mégaoctets (Mo), qui peut prendre en charge 16 trames kilo-octets (Ko). Le nœud local permet à une application FMI de spécifier que le transfert de données doit être en unités plus petites, appelées segments.

Voir aussi

Ouverture de la connexion PLU
PLU Session
Chaînage sortant
Chaînage entrant
Distribution de segments
Crochets
Direction
Rythme et division en sections
Confirmation et rejet des données]
Arrêt et quiesce
Récupération
Application-Initiated Résiliation
LUSTATs]
Données du moniteur de temps de réponse