[omniORB] Problem connecting naming service

[Duncan Grisby]

On Thursday 5 October, "K.D.Welast at t-online.de" wrote:

[...]
> I have done the test with 4.1.0 RC 1 and the problem is still there. 
> The version 4.1.0 RC 1 binaries are building with VC 7 SP1 on WinXP SP2
> 
> Below the trace with -ORBtraceLevel 40 -ORBtraceInvocations 1 for the
> versions 4.10 RC1 and 4.07

OK, now I've looked at it closer, it's not the issue I thought it was at
all. The problem is actually that Visibroker is returning a strange IOR
in the location forward. Extracting it from the trace, and dumping it
with catior, it looks like this:

Type ID: "IDL:omg.org/CosNaming/NamingContextExt:1.0"
Profiles:
1. IIOP 1.2 164.23.185.14 2809 ".PMC......../CONTEXT_POAMaster. ....2"
            unknown tag(0x56495303) 0x00070801ff
            TAG_ORB_TYPE 0x56495300
            TAG_CODE_SETS char native code set: ISO-8859-1
                          char conversion code set: UTF-8
                          wchar native code set: UTF-16
                          wchar conversion code set: 
            

2. IIOP 1.2 164.23.131.250 2809 ".PMC......../CONTEXT_POAMaster. ....2"
            unknown tag(0x56495303) 0x00070801ff
            TAG_ORB_TYPE 0x56495300
            TAG_CODE_SETS char native code set: ISO-8859-1
                          char conversion code set: UTF-8
                          wchar native code set: UTF-16
                          wchar conversion code set: 


So you can see it has two IIOP profiles. The proper way to represent
multiple IP addressees is with a TAG_ALTERNATE_IIOP_ADDRESS.
Constructing an IOR with omniNames, it looks like this:

Type ID: "IDL:omg.org/CosNaming/NamingContextExt:1.0"
Profiles:
1. IIOP 1.2 164.23.185.14 2809 "NameService"
            TAG_ORB_TYPE omniORB
            TAG_CODE_SETS char native code set: ISO-8859-1
                          char conversion code set: UTF-8
                          wchar native code set: UTF-16
                          wchar conversion code set: UTF-16
            
            TAG_ALTERNATE_IIOP_ADDRESS 164.23.131.250 2809

You see it has just one IIOP profile, with two addresses in it. With an
IOR like that, omniORB does the right thing.

Clearly Visibroker is using both IIOP profiles. I think that's wrong
according to the CORBA 2.6 spec. In section 13.6.3 is 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.

Then in section 13.6.7, it says:

  The following rules augment the preceding discussion:

  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.
  
  ...

So based on point 2, I think omniORB is right to only use the details in
the first IIOP profile, and ignore the second one. It wouldn't be hard
to extend omniORB to use all the IIOP profiles when picking the
endpoints to try, but I think the spec says it's wrong to do that.

Cheers,

Duncan.

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