15.4.1 GIOP Message Header

   All GIOP messages begin with the following header, defined in OMG IDL:

   module GIOP { // IDL extended for version 1.1, 1.2, and 1.3 struct Version {

   enum MsgType_1_0 { // Renamed from MsgType

   Request, Reply, CancelRequest,LocateRequest, LocateReply,CloseConnection, MessageError

   };

   #else // GIOP 1.1 enum MsgType_1_1 {

   Request, Reply, CancelRequest,LocateRequest, LocateReply,CloseConnection, MessageError,Fragment // GIOP 1.1 addition

   }; #endif // GIOP_1_1

   // GIOP 1.0

   struct MessageHeader_1_0 { // Renamed from MessageHeader char magic [4];Version GIOP_version; boolean byte_order; octet message_type; unsigned long message_size;

   };

   // GIOP 1.1

   struct MessageHeader_1_1 { char magic [4];Version GIOP_version;octet flags; // GIOP 1.1 change octet message_type; unsigned long message_size;

   };

   // GIOP 1.2, 1.3typedef MessageHeader_1_1 MessageHeader_1_2;typedef MessageHeader_1_1 MessageHeader_1_3;

   };

   The message header clearly identifies GIOP messages and their byte-ordering. The header is independent of byte ordering except for the field encoding message size.

• magic identifies GIOP messages. The value of this member is always the four (upper case) characters “GIOP,? encoded in ISO Latin-1 (8859.1).

• GIOP_version contains the version number of the GIOP protocol being used in the message. The version number applies to the transport-independent elements of this specification (i.e., the CDR and message formats) that constitute the GIOP. This is not equivalent to the IIOP version number (as described in Section 15.3.6, “Object References,? on page 15-30) though it has the same structure. The major GIOP version number of this specification is one (1); the minor versions are one (1), two (2), and three (3).

   A server implementation supporting a minor GIOP protocol version 1.n (with n > 0 and n < 3), must also be able to process GIOP messages having minor protocol version 1.m, with m less than n. A GIOP server, which receives a request having a greater minor version number than it supports, should respond with an error message having the highest minor version number that that server supports, and then close the connection.

   A client should not send a GIOP message having a higher minor version number than that published by the server in the tag Internet IIOP Profile body of an IOR.

• byte_order (in GIOP 1.0 only) indicates the byte ordering used in subsequent elements of the message (including message_size). A value of FALSE (0) indicates big-endian byte ordering, and TRUE (1) indicates little-endian byte ordering.

• flags (in GIOP 1.1, 1.2, and 1.3) is an 8-bit octet. The least significant bit indicates the byte ordering used in subsequent elements of the message (including message_size). A value of FALSE (0) indicates big-endian byte ordering, and TRUE (1) indicates little-endian byte ordering. The byte order for fragment messages must match the byte order of the initial message that the fragment extends.

   The second least significant bit indicates whether or not more framents follow. A value of FALSE (0) indicates this message is the last fragment, and TRUE (1) indicates more fragments follow this message.

   The most significant 6 bits are reserved. These 6 bits must have value 0 for GIOP version 1.1, 1.2, and 1.3.

• message_type indicates the type of the message, according to Table 15-3; these correspond to enum values of type MsgType.

• message_size contains the number of octets in the message following the message header, encoded using the byte order specified in the byte order bit (the least significant bit) in the flags field (or using the byte_order field in GIOP 1.0). It refers to the size of the message body, not including the 12-byte message header. This count includes any alignment gaps and must match the size of the actual request parameters (plus any final padding bytes that may follow the parameters to have a fragment message terminate on an 8-byte boundary).

   A MARSHAL exception with minor code 7 indicates that fewer bytes were present in a message than indicated by the count. (This condition can arise if the sender sends a message in fragments, and the receiver detects that the final fragment was received but contained insufficient data for all parameters to be unmarshaled.).

   A MARSHAL exception with minor code 8 indicates that more bytes were present in a message than indicated by the count. Depending on the ORB implementation, this condition may be reported for the current message or the next message that is processed (when the receiver detects that the previous message is not immediately followed by the GIOP magic number).

   The use of a message size of 0 with a Request, LocateRequest, Reply, or LocateReply message is reserved for future use.

   For GIOP version 1.2, and 1.3, if the second least significant bit of Flags is 1, the sum of the message_size value and 12 must be evenly divisible by 8.

   Messages with different GIOP minor versions may be mixed on the same underlying transport connection.