15.4.9 Fragment Message

   This message is added in GIOP 1.1.

   The Fragment message is sent following a previous request or response message that has the more fragments bit set to TRUE in the flags field.

   All of the GIOP messages begin with a GIOP header. One of the fields of this header is the message_size field, a 32-bit unsigned number giving the number of bytes in the message following the header. Unfortunately, when actually constructing a GIOP Request or Reply message, it is sometimes impractical or undesirable to ascertain the total size of the message at the stage of message construction where the message header has to be written. GIOP 1.1 provides an alternative indication of the size of the message, for use in those cases.

   In GIOP 1.1, a Request or Reply message can be broken into multiple fragments. In GIOP 1.2 and 1.3, a Request, Reply, LocateRequest, or LocateReply message can be broken into multiple fragment. The first fragment is a regular message (e.g.,

   Request or Reply) with the more fragments bit in the flags field set to TRUE. This initial fragment can be followed by one or more messages using the fragment messages. The last fragment shall have the more fragment bit in the flag field set to FALSE.

   A CancelRequest message may be sent by the client before the final fragment of the message being sent. In this case, the server should assume no more fragments will follow.

   Note – A GIOP client that fragments the header of a Request message before sending the request ID may not send a CancelRequest message pertaining to that request ID and may not send another Request message until after the request ID is sent.

   A primitive data type of 8 bytes or smaller should never be broken across two fragments.

   In GIOP 1.1, the data in a fragment is marshaled with alignment relative to its position in the fragment, not relative to its position in the whole unfragmented message.

   For GIOP version 1.2 and 1.3, the total length (including the message header) of a fragment other than the final fragment of a fragmented message are required to be a multiple of 8 bytes in length, allowing bridges to defragment and/or refragment messages without having to remarshal the encoded data to insert or remove padding.

   For GIOP version 1.2 and 1.3, a fragment header is included in the message, immediately after the GIOP message header and before the fragment data. The request ID, in the fragment header, has the same value as that used in the original message associated with the fragment.

   The byte order and GIOP protocol version of a fragment shall be the same as that of the message it continues.

   module GIOP {//IDL extension for GIOP 1.2 and 1.3 // GIOP 1.2, 1.3 struct FragmentHeader_1_2 {

   unsigned long request_id; }; typedef FragmentHeader_1_2 FragmentHeader_1_3;

   };

   15.5 GIOP Message Transport

   The GIOP is designed to be implementable on a wide range of transport protocols. The GIOP definition makes the following assumptions regarding transport behavior:

• The transport is connection-oriented. GIOP uses connections to define the scope and extent of request IDs.

• The transport is reliable. Specifically, the transport guarantees that bytes are delivered in the order they are sent, at most once, and that some positive acknowledgment of delivery is available.

• The transport can be viewed as a byte stream. No arbitrary message size limitations, fragmentation, or alignments are enforced.

• The transport provides some reasonable notification of disorderly connection loss. If the peer process aborts, the peer host crashes, or network connectivity is lost, a connection owner should receive some notification of this condition.

• The transport’s model for initiating connections can be mapped onto the general connection model of TCP/IP. Specifically, an agent (described herein as a server) publishes a known network address in an IOR, which is used by the client when initiating a connection.

   The server does not actively initiate connections, but is prepared to accept requests to connect (i.e., it listens for connections in TCP/IP terms). Another agent that knows the address (called a client) can attempt to initiate connections by sending connect requests to the address. The listening server may accept the request, forming a new, unique connection with the client, or it may reject the request (e.g., due to lack of resources). Once a connection is open, either side may close the connection. (See Section 15.5.1, “Connection Management,? on page 15-47 for semantic issues related to connection closure.) A candidate transport might not directly support this specific connection model; it is only necessary that the transport’s model can be mapped onto this view.