Formati di messaggi FMI

Questa sezione descrive i formati di messaggio per l'interfaccia di gestione delle funzioni (FMI). I formati di messaggio vengono presentati in una notazione indipendente dal linguaggio. I dettagli della notazione e dei presupposti chiave relativi al contenuto dei formati di messaggio sono i seguenti:

  • Riservato indica che il campo è impostato su zero (per un campo numerico) o tutti i valori Null (per i nomi) dal mittente del messaggio.

  • Undefined indica che il valore del campo è indeterminato. Il campo non è impostato dal mittente e non deve essere esaminato dal destinatario del messaggio.

  • I campi che occupano due byte, ad esempio opresid nella richiesta Open(PLU), sono rappresentati con i byte più aritmetici nel byte più basso, indipendentemente dall'orientamento normale usato dal processore in cui viene eseguito il software. Vale a dire, il valore a 2 byte 0x1234 ha il 0x12 byte nell'indirizzo di byte più basso. Tuttavia, i campi seguenti sono eccezioni:

    • I campi srci e desti nelle intestazioni del buffer vengono archiviati nel formato locale dell'applicazione che li assegna, perché solo l'applicazione di assegnazione deve interpretare questi valori.

    • I campi iniziali e finali negli elementi vengono sempre archiviati in orientamento a byte basso e alto byte (l'orientamento normale di un processore Intel).

  • I messaggi sono costituiti da buffer costituiti da un'intestazione del buffer e da zero o più elementi buffer. Per altre informazioni sui formati di buffer, vedere Messaggi.

  • Le applicazioni devono assegnare valori di indice univoci (I) per ogni connessione LPI attiva all'interno del nodo. In particolare, la richiesta Open(SSCP) deve essere diversa dall'indice di origine che invia in risposta all'oggetto Open(PLU). Inoltre, zero non deve essere usato come valore di I. Un valore di I significa che il mittente del messaggio invita il destinatario del messaggio a assegnare un valore I.

  • Il campo iniziale in ogni elemento restituisce l'offset del primo byte di dati nell'elemento dopo il campo trpad .

    Per le applicazioni di unità non logiche (LUA), l'avvio sarà 1 (i dati iniziano nel byte dopo il campo trpad), 10 (nove byte di riempimento sono inclusi tra il campo trpad e l'inizio dei dati) o 13 (12 byte di riempimento sono inclusi tra il campo trpad e l'inizio dei dati).

    Per le applicazioni LUA, startd è 4 (tre byte di spaziatura interna tra il campo trpad e l'inizio dei dati) nel primo elemento di un messaggio e 13 (12 byte di riempimento) negli elementi successivi.

    Il nodo locale usa byte aggiuntivi per informazioni aggiuntive sull'intestazione. Ciò consente di evitare di copiare i dati in un nuovo buffer quando si aggiungono queste informazioni.

  • Poiché startd indica l'indice in dataru a partire da 1, non 0, il primo byte di dati validi è sempre in dataru[startd-1].

  • Se l'avvio è maggiore del termine, nel messaggio non sono presenti dati validi.

  • Tutti i campi all'interno di dataru sono di tipo CHAR, ad eccezione del caso in cui le osservazioni indicano in caso contrario.

  • Si noti che se un elemento buffer ha un inizio di 1, 10 o 13, questo vale solo per l'elemento iniziale nella catena di elementi e gli elementi successivi della catena hanno un inizio di 1. I messaggi con due catene di elementi collegati distinti nei formati di messaggio (ad esempio Open(PLU) Request e Open(PLU) OK Response hanno il campo iniziale negli elementi all'inizio delle catene come valore (1, 10 o 13) specificato nel formato del messaggio e i campi iniziali in tutti gli altri elementi come 1.

Contenuto della sezione