15.5.1 Connection Management

   For the purposes of this discussion, the roles client and server are defined as follows:

• A client initiates the connection, presumably using addressing information found in an object reference (IOR) for an object to which it intends to send requests.

• A server accepts connections, but does not initiate them.

   These terms only denote roles with respect to a connection. They do not have any implications for ORB or application architectures.

   In GIOP protocol versions 1.0 and 1.1, connections are not symmetrical. Only clients can send Request, LocateRequest, and CancelRequest messages over a connection, in GIOP 1.0 and 1.1. In all GIOP versions, a server can send Reply, LocateReply, and CloseConnection messages over a connection; however, in GIOP 1.2, 1.3 the client can send them as well. Either client or server can send MessageError messages, in GIOP 1.0 and 1.1.

   If multiple GIOP versions are used on an underlying transport connection, the highest GIOP version used on the connection can be used for handling the close. A CloseConnection message sent using any GIOP version applies to all GIOP versions used on the connection (i.e., the underlying transport connection is closed for all GIOP versions). In particular, if GIOP version 1.2 or higher has been used on the connection, the client can send the CloseConnection message by using the highest GIOP version in use.

   Only GIOP messages are sent over GIOP connections.

   Request IDs must unambiguously associate replies with requests within the scope and lifetime of a connection. Request IDs may be re-used if there is no possibility that the previous request using the ID may still have a pending reply. Note that cancellation does not guarantee no reply will be sent. It is the responsibility of the client to generate and assign request IDs. Request IDs must be unique among both Request and LocateRequest messages.

   15.5.1.1 Connection Closure

   Connections can be closed in two ways: orderly shutdown, or abortive disconnect.

   For GIOP versions 1.0, and 1.1:

• Orderly shutdown is initiated by servers sending a CloseConnection message, or by clients just closing down a connection.

• Orderly shutdown may be initiated by the client at any time.

• A server may not initiate shutdown if it has begun processing any requests for which it has not either received a CancelRequest or sent a corresponding reply.

• Orderly shutdown is initiated by either the originating client ORB (connection initiator) or by the server ORB (connection responder) sending a CloseConnection message

• If the ORB sending the CloseConnection is a server, or bidirectional GIOP is in use, the sending ORB must not currently be processing any Requests from the other side.

• The ORB that sends the CloseConnection must not send any messages after the CloseConnection.

• If either ORB detects connection closure without receiving a CloseConnection message, it must assume an abortive disconnect has occurred, and treat the condition as an error.

• If there are any pending non-oneway requests, which were initiated on a connection by the ORB shutting down that connection, the connection-peer ORB should consider them as canceled.

• If an ORB receives a CloseConnection message from its connection-peer ORB, it should assume that any outstanding messages (i.e., without replies) were received after the connection-peer ORB sent the CloseConnection message, were not processed, and may be safely re-sent on a new connection.

• After issuing a CloseConnection message, the issuing ORB may close the connection. Some transport protocols (not including TCP) do not provide an “orderly disconnect? capability, guaranteeing reliable delivery of the last message sent. When GIOP is used with such protocols, an additional handshake needs to be provided as part of the mapping to that protocol's connection mechanisms, to guarantee that both ends of the connection understand the disposition of any outstanding GIOP requests.

• If a client detects connection closure without receiving a CloseConnection message, it must assume an abortive disconnect has occurred, and treat the condition as an error.

For GIOP Version 1.2, 1.3:

• If bidirectional GIOP is in use, the conditions of Section 15.8, “Bi-Directional GIOP,? on page 15-56 apply.

For all uses of CloseConnection (for GIOP versions 1.0, 1.1, 1.2, and 1.3):

   15.5.1.2 Multiplexing Connections

   A client, if it chooses, may send requests to multiple target objects over the same connection, provided that the connection’s server side is capable of responding to requests for the objects. It is the responsibility of the client to optimize resource usage by reusing connections, if it wishes. If not, the client may open a new connection for each active object supported by the server, although this behavior should be avoided.