Formats de message FMI
Cette section décrit les formats de message pour l’interface de gestion des fonctions (FMI). Les formats de message sont présentés dans une notation indépendante de la langue. Les détails de la notation du format de message et les hypothèses clés relatives au contenu des formats de message sont les suivants :
Reserved indique que le champ est défini sur zéro (pour un champ numérique) ou sur toutes les valeurs null (pour les noms) par l’expéditeur du message.
Undefined indique que la valeur du champ est indéterminée. Le champ n’est pas défini par l’expéditeur et ne doit pas être examiné par le destinataire du message.
Les champs qui occupent deux octets, tels que l’opresid dans la demande Open(PLU), sont représentés avec l’octet le plus arithmétiquement significatif dans l’adresse d’octet la plus basse, quelle que soit l’orientation normale utilisée par le processeur sur lequel le logiciel s’exécute. Autrement dit, la valeur de 2 octets 0x1234 a l'0x12 d’octet dans l’adresse d’octet la plus basse. Toutefois, les champs suivants sont des exceptions :
Les champs srci et desti dans les en-têtes de mémoire tampon sont stockés au format local de l’application qui les affecte, car seule l’application affectante doit interpréter ces valeurs.
Les champs démarrés et terminés dans les éléments sont toujours stockés dans une orientation à octets bas et à octets élevés (orientation normale d’un processeur Intel).
Les messages sont composés de mémoires tampons composées d’un en-tête de mémoire tampon et de zéro ou plusieurs éléments de mémoire tampon. Pour plus d’informations sur les formats de mémoire tampon, consultez Messages.
Les applications doivent affecter des valeurs d’index uniques (I) pour chaque connexion LPI active au sein du nœud. En particulier, la demande Open(SSCP) doit être différente de l’index source qu’elle envoie en réponse à Open(PLU). En outre, zéro ne doit pas être utilisé comme valeur I. Une valeur I de zéro signifie que l’expéditeur du message invite le destinataire du message à attribuer une valeur I.
Le champ démarré dans chaque élément donne le décalage du premier octet de données de l’élément après le champ trpad .
Pour les applications d’application d’unité non logique (LUA), le démarrage est 1 (les données commencent dans l’octet après le champ trpad ), 10 (neuf octets de remplissage sont inclus entre le champ trpad et le début des données) ou 13 (12 octets de remplissage sont inclus entre le champ trpad et le début des données).
Pour les applications LUA, la valeur démarrée est de 4 (trois octets de remplissage entre le champ trpad et le début des données) dans le premier élément d’un message et de 13 (12 octets de remplissage) dans les éléments suivants.
Le nœud local utilise des octets supplémentaires pour les informations d’en-tête supplémentaires. Cela évite d’avoir à copier des données dans une nouvelle mémoire tampon lors de l’ajout de ces informations.
Étant donné que startd indique l’index dans dataru à partir de 1, et non de 0, le premier octet de données valides se trouve toujours à dataru[startd–1].
Si startd est supérieur à endd, il n’y a pas de données valides dans le message.
Tous les champs dans dataru sont de type CHAR, sauf si les remarques indiquent le contraire.
Notez que lorsqu’un élément de mémoire tampon a un démarrage de 1, 10 ou 13, cela s’applique uniquement à l’élément initial dans la chaîne d’éléments, et que les éléments suivants de la chaîne ont un démarrage de 1. Les messages avec deux chaînes d’éléments liées distinctes dans les formats de message (par exemple Open(PLU) Request et Open(PLU) OK Response) ont le champ démarré dans les éléments au début des chaînes comme valeur (1, 10 ou 13) donné dans le format de message, et les champs démarrés dans tous les autres éléments comme 1.