| Previous | Table of Contents | Next |
The specification of GIOP connection management, in GIOP minor versions 1.0 and 1.1, states that connections are not symmetrical.
For example, only clients that initialize connections can send requests, and only servers that accept connections can receive
them.
This GIOP 1.0 and 1.1 restriction gives rise to significant difficulties when operating across firewalls. It is common for
firewalls not to allow incoming connections, except to certain well-known and carefully configured hosts, such as dedicated
HTTP or FTP servers. For most CORBA-over-the-internet applications it is not practicable to require that all potential client
firewalls install GIOP proxies to allow incoming connections, or that any entities receiving callbacks will require prior
configuration of the firewall proxy.
An applet, for example, downloaded to a host inside such a firewall will be restricted in that it cannot receive requests
from outside the firewall on any object it creates, as no host outside the firewall will be able to connect to the applet
through the client's firewall, even though the applet in question would typically only expect callbacks from the server it
initially registered with.
In order to circumvent this unnecessary restriction, GIOP minor protocol version 1.2 or
1.3 specifies that the asymmetry stipulation above be relaxed in cases where the client and the server agree on it. In these
cases, the client (the applet in the above case) would still initiate the connection to the server, but any requests from
the server on any objects.
The client creates an object for exporting to a server, and arranges that the server receive an IOR for the object. The most
common use case would be for the client to pass the IOR as a parameter in a GIOP request, but other mechanisms are possible,
such as the use of a Name Service. If the client ORB policy permits bi-directional use of a connection, a Request message
should contain an IOP::ServiceContext structure in its Request header, which indicates that this GIOP connection is bidirectional.
The service context may provide additional information that the server may need to invoke the callback object. To determine
whether an ORB may support bi
directional GIOP new policies has been defined (Section 15.9, “Bi-directional GIOP
policy,? on page 15-60).
Each mapping of GIOP to a particular transport should define a transport-specific bidirectional service context, and have
an IOP::ServiceId allocated by the OMG. It is recommended that names for this service context follows the pattern BiDir<protocolname>,
where <protocol name> identifies a mapping of GIOP to a transport protocol (e.g., for IIOP the name is BiDirIIOP). The service
context for bi
directional IIOP is defined in Section 15.8.1, “Bi-Directional IIOP,? on page 15-58.
The server receives the Request, which contains a bi-directional IOP::ServiceContext. If the server supports bi-directional
connections for that protocol, it may now send invocations along the same connection to any object that supports the particular
protocol and matches the particular location information found in the bi-directional service context. If the server does not
support bi-directional connections for that protocol, the service context can be ignored.
The data encapsulated in the BiDirIIOPServiceContext structure (see below), which is identified by the ServiceId BI_DIR_IIOP
as defined in Section 13.7, “Service
Context,? on page 13-28, allows the ORB to determine whether it needs to open a new
connection in order to invoke on an object. If a host and port pair in a listen_point list matches a host and port of an object
to which it does not yet have a connection (a callback object newly received, for instance), rather than open a new connection,
the server may re-use any of the connections on which the listen_point data was received.
A server talking to a client on a bi-directional GIOP connection can use any message type traditionally used by clients only,
so it can use Request, LocateRequest, CancelRequest, MessageError, and Fragment (for a Request or LocateRequest). Similarly
the client can use message types traditionally used only by servers: Reply, LocateReply, MessageError, CloseConnection, and
Fragment (for a Reply or LocateReply).
CloseConnection messages are a special case however. Either ORB may send a CloseConnection
message, but the conditions in Section 15.5.1, “Connection
Management,? on page 15-47 apply.
Bi-directional GIOP connections modify the behavior of Request IDs. In the GIOP
specification, Section 15.5.1, “Connection Management,? on page 15-47, it is noted
that “Request IDs must unambiguously associate replies with requests within the scope and lifetime of a connection.? This
property of unambiguous association of requests and replies must be preserved while permitting each end to generate Request
Ids for new requests independently. To ensure this, on a connection that is used bidirectionally in GIOP 1.2, and 1.3, the
connection originator shall assign only even valued Request IDs and the other side of the connection shall assign only odd
valued Request IDs. This requirement applies to the full lifetime of the connection, even before a BiDirIIOPServiceContext
is transmitted. A connection on which this regime of Request ID assignment is not used, shall never be used to transmit bidirectional
GIOP 1.2, or 1.3 messages.
It should be noted that a single-threaded ORB needs to perform event checking on the connection, in case a Request from the
other endpoint arrives in the window between it sending its own Request and receiving the corresponding reply; otherwise a
client and server could send Requests simultaneously, resulting in deadlock. If the client cannot support event checking,
it must not indicate that bi-directionality is supported. If the server cannot support event checking, it must not make callbacks
along the same connection even if the connection indicates it is supported.
A server making a callback to a client cannot specify its own bi-directional service context – only the client can announce
the connection's bi-directionality.
An important security issue should be observed in the use of bi-directional GIOP. In the absence of other security mechanisms,
a malicious client may claim that its connection is Bi-Directional for use with any host and port it chooses. In particular
it may specify the host and port of security sensitive objects not even resident on its host. All the client has to do is
pass the host and port in the listen data service context and the server may then invoke a masquerading object instead. In
general, and in the absence of other security mechanisms, a server that has accepted an incoming connection has no way to
discover the identity or verify the integrity of the client that initiated the connection. If the server has doubts in the
integrity of the client, it is recommended that bi-directional GIOP is not used.