| Previous | Table of Contents | Next |
Agents that are capable of accepting object requests or providing locations for objects
(i.e., servers) publish TCP/IP addresses in IORs, as described in Section 15.7.2, “IIOP
IOR Profiles,? on page 15-52. A TCP/IP address consists of an IP host address,
typically represented by a host name, and a TCP port number. Servers must listen for connection requests.
A client needing an object’s services must initiate a connection with the address specified in the IOR, with a connect request.
The listening server may accept or reject the connection. In general, servers should accept connection requests if possible,
but ORBs are free to establish any desired policy for connection acceptance (e.g., to enforce fairness or optimize resource
usage).
Once a connection is accepted, the client may send Request, LocateRequest, or CancelRequest messages by writing to the TCP/IP
socket it owns for the connection. The server may send Reply, LocateReply, and CloseConnection messages by writing to its
TCP/IP connection. In GIOP 1.2, and 1.3, the client may send the CloseConnection message, and if BiDirectional GIOP is in
use, the client may also send Reply and LocateReply messages.
After receiving a CloseConnection message, an ORB must close the TCP/IP connection. After sending a CloseConnection, an ORB
may close the TCP/IP connection immediately, or may delay closing the connection until it receives an indication that the
other side has closed the connection. For maximum interoperability with ORBs using TCP implementations that do not properly
implement orderly shutdown, an ORB may wish to only shutdown the sending side of the connection, and then read any incoming
data until it receives an indication that the other side has also shutdown, at which point the TCP connection can be closed
completely.
Given TCP/IP’s flow control mechanism, it is possible to create deadlock situations between clients and servers if both sides
of a connection send large amounts of data on a connection (or two different connections between the same processes) and do
not read incoming data. Both processes may block on write operations, and never resume. It is the responsibility of both clients
and servers to avoid creating deadlock by reading incoming messages and avoiding blocking when writing messages, by providing
separate threads for reading and writing, or any other workable approach. ORBs are free to adopt any desired implementation
strategy, but should provide robust behavior.