[omniORB] Fwd: problem accessing a TAO-based CORBA server on a multihomed setup using omniORB

[Duncan Grisby]

On Mon, 2017-10-30 at 14:28 +0100, Sylvain Joyeux via omniORB-list
wrote:

> I've been trying to access a TAO-based CORBA server which is on a
> multihomed machine. The name service is omniNames and the client is
> OmniORB-based.

Sorry for the huge delay in replying to this...

[...]
> Connecting fails with a NoUsableProfile error. The decoded IOR gives
> 
> 1. IIOP 1.2 10.0.2.15 51961 "....RSTX..Y.M.............."
[...]
> 2. IIOP 1.2 2.0.10.2 51961 "....RSTX..Y.M.............."
[...]
> I've debugged it in the omniorb source code, and it seems that
> omniorb restricts itself to the first IIOP profile it finds (which
> would explain the problem).
> 
> My questions:
>  - is the omniORB behavior intentional ? Is ill-defined in the
> standard / an omniORB bug / a TAO bug / none of the above ?

The CORBA standard is somewhat unclear. Section 13.6.3 or the 2.6 spec
(and 7.6.3 of the 3.3 interoperability spec, which has the same
wording) says:

    Object references have at least one tagged profile. Each profile
    supports one or more protocols and encapsulates all the basic
    information the protocols it supports need to identify an object.
    Any single profile holds enough information to drive a complete
    invocation using any of the protocols it supports; the content and
    structure of those profile entries are wholly specified by these
    protocols.

and then 13.6.7 (7.6.7 in 3.3) says...

    1. Profiles must be independent, complete, and self-contained. Their
       use shall not depend on information contained in another profile.

    2. Any invocation uses information from exactly one profile.


omniORB interprets the "any invocation uses information from exactly
one profile" to mean that if there are multiple IIOP profiles in an
IOR, it should pick just one of them, and it picks just the first one.

The unambiguous way to represent multiple IP addresses in an IOR is to
use a TAG_ALTERNATE_IIOP_ADDRESS profile component. omniORB fully
supports that, and that's what it uses for multi-address servers. Is it
possible to get TAO to use that form?

omniORB could of course be extended to handle the multiple separate
profiles, but it is somewhat painful because the object key could be
different in each profile (it looks like they are the same in both in
the TAO case). If the different profiles had different keys, the call
would have to be retried at a different level in omniORB's call chain
than its current multi-address retries.

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --