[omniORB] omniNames and multiple network interfaces

Duncan Grisby duncan at grisby.org
Fri Nov 18 09:51:40 GMT 2011

On Thu, 2011-11-10 at 16:53 +0100,
ext.erik.yderborg at se.transport.bombardier.com wrote:

> I run omniNames on Solaris, with multiple network interfaces. The
> primary IF picked by omniNames by default, is a private one (192.x..),
> not accessable from the outside. 

omniORB has no way to know which of your IP addresses is the one you
want to use, so it picks the first one the OS tells it. In your case,
that's the wrong one...

> To work around this I have realized I need to use -ignoreport and
> ORBendPoint (I use port 10111): 
> omniNames -start 10111 -ignoreport -ORBendPoint
> giop:tcp: 
> My question is: Is it possible to have omniNames work the same way as
> above, without supplying the ip hard coded? 

The problem is that without telling it the IP address you want, how is
it to know which one to pick?

What you can do is to tell it to publish all its IP addresses in its
IORs, then clients will see all its addresses and can pick the one that
works. Do that with

-ORBendPointPublish "all(addr)"

> I have tried '-ORBendPoint giop:tcp::10111', but then omniNames tries
> to communicate with its clients on the private ip. This is strange
> since the clients connect on the public ip. 

Why is that strange?  That is the default endpoint you'd have if you
didn't specify anything, meaning that omniORB picks an address to
publish, and it picks the wrong one for you.

omniNames doesn't connect to its clients -- the clients always connect
to it, using the address details in its object references. If a client
connects on the public IP (using an initial reference) but then receives
a NamingContext back from omniNames, that will have the private IP in
it, and the client won't be able to reach it.



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

More information about the omniORB-list mailing list