Aufbau des USP-Headers

Der Header enthält den Identifier, zwei Versionsfelder und ein Flagfeld, ein Typfeld und ein Längenfeld. Das beschriebene Protokoll wird von openUTM eingabeseitig erwartet. Es ist wie folgt aufgebaut:

Identifier ASCII, 4 Byte	Version Major 1 Byte	Version Minor 1 Byte	Flags 1 Byte	MsgType 1 Byte	MsgSize 4 Byte	Daten max 31988 Byte
| UTMS(55544D53)	| 01	| 01		| Typ der Nachricht	| 0000xxxx	| Daten

Erläuterung

Identifier

Das Identifikationsfeld muss für openUTM immer den ASCII-String "UTMS" (=0x55544D53) enthalten

Version Major

Im Versionsfeld Major muss immer 0x01 stehen.

Version Minor

Im Versionsfeld Minor muss der Wert 0x01 stehen.

Flags

Das Flagfeld ist ein Informationsfeld. Nur Bit 0x02 wird ausgewertet: Ist es gesetzt, folgt der Nachricht ein weiteres Fragment. Ist es nicht gesetzt, folgt kein Fragment. Alle anderen Bits sind für künftige Versionen reserviert.

MsgType

Im Typfeld kann 0x00, 0x01 oder 0x07 stehen:

• • • Nachrichten vom Client empfangen:
      Bei unfragmentierten Nachrichten setzt der Client MsgType auf den Wert 0x00. Bei fragmentierten Nachrichten setzt der Client MsgType beim ersten Fragment auf den Wert 0x00 (Bit 0x02 im Flagfeld ist gesetzt). Bei den Folgefragmenten wird MsgType auf den Wert 0x07 gesetzt (Bit 0x02 bleibt gesetzt). Beim letzten Folgefragment ist Bit 0x02 nicht gesetzt.

    • Nachrichten an Client senden:
      Wird ein USP-Header erzeugt (z.B. bei USP-HDR=ALL), dann setzt openUTM das Feld MsgType auf den Wert 0x01, bei Folgefragmenten auf 0x07.

MsgSize

Das Längenfeld MsgSize enthält die Länge der (Teil)nachricht einschließlich Header. Diese Länge darf eingabeseitig 32000 Byte und ausgabeseitig 32767 Byte nicht überschreiten. Die Nachrichtenlänge wird in Network Byte Order (Big Endian) übertragen. Mit Hilfe der C-Funktionen htonl (Host to network long) und ntohl (Network to Host long) kann zwischen lokaler Darstellung in Netzwerksicht konvertiert werden.

Beispiele

1. Der Client sendet Nachrichten an openUTM, siehe mit ausgelieferte Beispielsource SOCBSP.C:

   • • Der Client sendet eine Nachricht (ohne Fragmentierung)

     • Der Client sendet 2 Nachrichtenteile

     • Der Client sendet 3 Nachrichtenteile

   Anzahl Nachrichtenteile	Identifier	Major Version	Minor Version	Flag	MsgType	Size
   1 Gesamtnachricht	55544D53	01	01	00	00	0000nnnn
   2 Teile
   Teil 1	55544D53	01	01	02	00	0000nnnn
   Teil 2	55544D53	01	01	00	07	0000mmmm
   3 Teile
   Teil 1	55544D53	01	01	02	00	0000kkkk
   Teil 2	55544D53	01	01	02	07	0000nnnn
   Teil 3	55544D53	01	01	00	07	0000mmmm

2. Der Server sendet Nachrichten an den Client (es wird ein USP-Header erzeugt):

   • • Eine Gesamtnachricht (ohne Fragmentierung)

     • 3 Nachrichtenteile

   Anzahl Nachrichtenteile	Identifier	Major Version	Minor Version	Flag	MsgType	Size
   1 Gesamtnachricht	55544D53	01	01	00	01	0000nnnn
   3 Teile
   Teil 1	55544D53	01	01	02	01	0000kkkk
   Teil 2	55544D53	01	01	02	07	0000nnnn
   Teil 3		01	01	00	07	0000mmmm

kkkk, nnnn, mmmm sind die jeweiligen Längen der einzelnen Nachrichtenteile.