IT-SC book: Advanced CORBA® Programming with C++

close its connection, the client would conclude that the server had crashed and would raise an exception in the client application code.[5]

[5] In GIOP 1.2, a CloseConnection message can also be sent from client to server.

MessageError

This message is sent in response to any GIOP message that is malformed in some way. For example, MessageError is returned if a GIOP message contains the wrong magic value (a string other than GIOP in the first four bytes) or if the GIOP version number is unknown to the receiver.

Fragment

If a GIOP 1.1 client decides to send messages in fragments, the first fragment is a Request message with the fragment flag set to true. The remainder of the request is sent by the client in Fragment messages. Each fragment contains more data for the request, together with a flag that indicates whether more fragments are to follow. While there are more fragments to follow, the flag is true. The final Fragment message in a series of fragments sets this flag to false to indicate that the server has received the last fragment and can now start processing the request.

13.5 GIOP Connection Management

The interaction model seen by CORBA clients and servers is connectionless; a client simply sends a request whenever it feels like it, and the request causes a virtual function to be called in the server. Neither client nor server application code ever opens or closes a connection. However, GIOP requests are dispatched over a connection-oriented transport, so the CORBA run-time environment must take care of managing connections on behalf of clients and servers.

The CORBA specification does not require any particular connection management strategy for ORBs. Instead, GIOP specifies just enough about connection management to enable interoperability among implementations, and it provides sufficient hooks in the protocol to allow an ORB vendor to choose between simple and sophisticated connection management strategies.

On the client side, an ORB has considerable choice as to how it manages connections from clients to servers. For example, a simple-minded (and unrealistic) ORB could simply open and close a separate connection for every request made by a client. This would be a prohibitively slow (but compliant) implementation. A typical problem for ORBs is what to do if a client exceeds the number of connections that the operating system is willing to allocate to it. Depending on the vendor, the ORB might simply raise an exception to the application code when it runs out of connections, whereas a more sophisticated ORB might multiplex requests onto fewer connections than the number of target servers by dynamically opening and closing connections as necessary.

541

IT-SC book: Advanced CORBA® Programming with C++

On the server side, a similar problem presents itself to the ORB. If there are more clients who want to communicate with a server than the number of available connections, the server-side run time may simply stop accepting connections. In that case, clients receive a TRANSIENT exception when the TCP/IP connection timer expires. A more sophisticated ORB would send CloseConnection messages to clients that do not have outstanding requests and thereby reclaim idle connections for use with other clients.[6]

[6] Note that the number of clients that can concurrently have a request in progress is limited by the number of connections available to the server. GIOP does not permit a server to close a connection while a request is outstanding on that connection.

The specification leaves a wide range of choices open to ORB implementers to avoid restricting the environments in which ORBs can be used. For example, if CORBA were to require a complicated strategy for reusing connections, it would penalize an ORB that runs in an environment where connections are available in large numbers (the ORB vendor would have to implement the strategy without any real benefit). Conversely, an ORB may need to run in an embedded environment where connections are at a premium. In that case, the vendor can implement a strategy that aggressively reuses connections at the cost of sacrificing some performance.

In practice, most general-purpose ORBs open a connection when a client first uses an object reference to an object in a particular server, and they close the connection when the reference count on the proxy for the target object drops to zero. If a client holds multiple references to objects in the same server, most ORBs multiplex requests to all objects in that server over the same single connection. This means that the client uses only as many connections as there are distinct server processes it communicates with. On the server side, many ORBs simply give up and stop accepting connection requests when the server reaches its connection limit. Other ORBs use the CloseConnection message to reclaim idle connections. If you are planning to use a large number of clients (more than 100 or so) with the same server simultaneously, you should ask your ORB vendor about the connection management strategy for the server side.

13.6 Detecting Disorderly Shutdown

In Section 13.4.3, we mention that a server sends a CloseConnection message if it wants to close a connection. This means that a client can always distinguish orderly connection shutdown from disorderly connection shutdown. If the client-side run time encounters a broken connection without having first received a CloseConnection message, it can conclude either that the server has crashed or that connectivity is lost. In either case, it raises a system exception to the client application code, possibly after attempting to rebind first.[7]

[7] At least, that is the theory. In practice, we have seen defective implementations of TCP/IP that do not reliably report disorderly connection closure on non-UNIX platforms.

However, the same is not true for the server. If a client decides that it is finished with a server (typically because the reference count on the last proxy to an object in the server

542

IT-SC book: Advanced CORBA® Programming with C++

drops to zero), the client simply closes the connection without first sending a message. This means that the server simply sees a closed connection. The server cannot distinguish orderly connection closure from disorderly closure. For example, if the client crashes, the server just sees a closed connection but does not know why the connection was closed. (With GIOP 1.2, sending a CloseConnection message to indicate orderly connection closure is mandatory for both client and server. This mitigates, but does not eliminate, the problems we discuss in the remainder of this section.)

This has important ramifications for garbage collection and the life cycle of objects. Frequently, a server offers a factory operation to clients. Clients can create new objects in the server by invoking an operation and can later destroy the objects by invoking another operation (typically, by calling destroy or CosLife-Cycle::remove). A problem arises if a client crashes after it has created an object and therefore never gets around to deleting the object again. There is no way for the server to know whether the client has gone away permanently or simply has closed the connection temporarily because it is short of connections. This means that the server must keep the object alive because the server cannot know whether the object is still of interest to the client.

Some ORBs offer an API call that allows a server to monitor the state of network connections. If a network connection closes, the ORB invokes a callback function in the server application code. This gives the server an opportunity to clean up objects it has created on behalf of a client. However, any such strategy is fraught with problems. For one thing, the server must somehow be able to associate the closed connection with a particular client in order to determine which objects it should destroy. Second, because there is no CloseConnection message in GIOP from client to server (except for GIOP 1.2), monitoring of network connections makes assumptions about the connection management used by the client. In effect, the server assumes that if a client closes a connection, it means that the server can clean up the objects created by that client. This is not a valid assumption. For example, if the client is written using a different vendor's ORB, it may use an aggressive connection reuse strategy. In that case, the client might deliberately close a connection, but the server would conclude that the client has crashed and mistakenly destroy the objects created by the client.

If you decide to use extensions provided by your ORB vendor to monitor connection closure, be aware that you are outside the guarantees provided by the GIOP specification. If you know that clients will be written using the same vendor's ORB, things will work fine. But keep in mind that using connection closure for garbage collection relies on proprietary extensions and may not work with clients using another ORB. We discuss other, more portable strategies for garbage collection in Chapter 12.

13.7 An Overview of IIOP

GIOP specifies most of the protocol details that are necessary for clients and servers to communicate. GIOP is independent of a particular transport and is therefore an abstract protocol, whereas IIOP is specific to TCP/IP and is therefore a concrete implementation (or mapping) of GIOP. To turn GIOP into a concrete protocol, IIOP merely needs to

543

IT-SC book: Advanced CORBA® Programming with C++

specify the encoding of IORs. Recall from Section 2.5.3 that an IOR consists of three main components: the repository ID, the endpoint information, and the object key. IIOP merely specifies how an IOR encodes the TCP/IP addressing information inside an IOR, so the client can establish a connection to the server to send a request.

Like GIOP, IIOP has been revised twice since its inception, so CORBA specifies IIOP 1.0, 1.1, and 1.2. IIOP 1.1 adds the notion of tagged components to an IOR. Tagged components are required to support some of the newer features of CORBA, such as support for different wide character codesets. IIOP 1.2 supports the bidirectional functionality of GIOP 1.2.

Any version of IIOP references can be carried over any version of GIOP. However, for bidirectional functionality to be available, IIOP 1.2 requires GIOP 1.2 or later.

The endpoint information inside an IOR that uses IIOP is encoded according to the following IDL:

sequence<IOP::TaggedComponent> components; };

};

We show the version 1.1 and 1.2 definition here (the 1.0 definition is identical except that it does not use tagged components). A structure of type ProfileBody_1_1 completely identifies the target object of a request: both the host and port at which the server can be found and the object in that server the request is for.

The iiop_version field indicates the major and minor revision of the protocol.

The host and port fields specify the host and port number at which the server listens for requests. The host can be encoded either in dotted-decimal notation (such as 234.234.234.234) or as a host name (such as acme.com).

The object_key field is a sequence of octets that identifies the particular target object. The components field contains a sequence of tagged components (for IIOP 1.1 only). Each tagged component is a structure containing two fields. The first field identifies the type of component, and the second one contains the data for that component (see page 628).

544