[omniORB] Curious omniNames Behavior

[Steven W. Brenneis]

Ken Feuerman wrote:
> 
> Thanks Bjorn & Steven for your replies.
> 
> Both of you mentioned the Win32 Registry entry for recording the IOR
> generated in the start call to omniNames.  True that I haven't been
> recording that entry into the registry, because I'm working with another
> ORB that also must get a hold of the NameService root context (I record the
> root context IOR into a "well-known" file, and all processes in my system
> know to look there regardless of which ORB they're using).
> 
> But what's curious is that this problem of generating a localhost-based IOR
> has never come up before on machines with fixed IP addresses, only on
> DHCP-based machines.  In other words, on hosts with fixed IP addresses, I
> can omit the registry entry for the NameService, yet still always generate
> a correct (non-127.0.0.1) IOR.
> 

With omniORB on NT (jump in if I go wrong here David or Sai-Lai) you
must either provide an initial host and port through the ORB
initialization or you must provide the registry entry in order to
resolve the initial Name Service reference in any ORB.  There is no
other way to do this that I am aware of.

As far as I know, the WinSock stack is completely unaware of DHCP. 
Therefore, omniORB is also unaware.  Changing DHCP addresses would be a
management issue.  I have seen the localhost IOR generated on NT when
the registry entry was not present on machines with fixed IP addresses. 
This may be coincidental.  I have always run the Name Service on the PDC
or BDC in a Microsoft network and they generally have fixed addresses.

> The real question I have is:  Suppose I have the situation where omniNames
> is restarted on Machine A displaying this localhost-based IOR.  Suppose
> further that I have a hold of the original IOR with the correct IP address
> encoded from the time when the omniNames was originally started.  Should I
> expect this behavior where processes on Machine A can indeed contact the
> NameService using the original IOR, but processes on some remote Machine B
> can't (using the same original IOR)?
> 

On NT, omniNames must have the registry entry with the -start option
generated IOR in order to function properly.  On other platforms it must
have the configuration file as Bjorn pointed out.  In the absence of
these steps, the Name Service may run on the system, but it will not
answer to requests generated from remote hosts which use the correct IOR
or initial host/port information.

> Thanks for your advice/help!
> 
> --Ken Feuerman.