CORBA 3.5b1 RTF Avatar
  1. OMG Issue

CORBA35 — when is a connection a "bi-directional connection"?

  • Key: CORBA35-265
  • Legacy Issue Number: 7356
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Dave Stringer)
  • Summary:

    The discussion on when to send BiDirIds over connections is floundering.
    In part, I think this is due to a lack of precision in our thinking (and more
    importantly in the adopted firewall spec we are working from).

    When does a GIOP connection become bi-directional? The implementation
    of the connection-initiator protocol engine must know this. Before this
    event it has to treat a GIOP Request message as a protocol error and after
    the event it has to dispatch the request.

    There seems to be an assumption (or more than one) that there is a
    relationship between an Object Reference (i.e. the programming language
    artefact representing CORBA::Object) and a GIOP connection.

    Whilst it is true that an implementation of the CORBA spec will provide a
    relationship (else an invocation cannot result in a GIOP Request message)
    the particular relationship was left to ORB implementers to provide for
    flexibility of implementation. Specifically, such a relationship is not prescribed
    in the CORBA specification (nor should it be).

    I suggest it would be dangerous to define a GIOP connection to change state
    when an Object Reference that (in some ill-defined way) "points to" a server
    that is the target of that connection, undergoes a policy change (i.e. its BiDir
    Offer policy is set to Allow).

    Instead, a GIOP connection presumably becomes bi-directional when an
    invocation on an Object Reference, with an effective Offer Policy of Allow, results
    in a Request message being sent over that connection.

    The specification must be explicit over which event causes the connection to
    become bi-directional.

    Also, can a connection cease to be bi-directional? For example if either the
    Object Reference invoked above or the POA with "Export = Allow" are destroyed.
    Again this would appear to be fraught with problems, leading to the assumption
    that the GIOP connection, once bi-directional, remains bi-directional until it is
    closed.

    Lastly, the closing of idle connections and the subsequent re-connection has
    hitherto been a matter for ORB implementers (Messaging::RebindPolicy not
    withstanding). This is unfortunate as an application won't be aware of the ORB
    having conserved resources in this way and the ORB should not be expected to
    provide session semantics that span multiple tcp connections (this is currently
    stated in the description of NegotiateSession).

  • Reported: UML 2.0 — Tue, 18 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:33 GMT