Outlines how to use CORBA to distribute applications. Differs by CORBA implementation and whether you are using DNS names or IP addresses. Examples below support the ACE/TAO and OmniORB CORBA implementations.

Sample system:

  • Deploying components in demo.xml with deployer-corba, on with IP address
  • Running a GUI program demogui to connect to deployer components, on with IP address
  • Use a name server without multi-casting[1], on
  • Using a bash shell.
  • Both machines are gnulinux (though this has been verified with macosx, and mixing macosx and gnulinux)

Working DNS

If you have working forward and reverse DNS entries (ie dig returns, and dig -x returns


machine1 \$ Naming_Service -m 0 -ORBListenEndpoints iiop:// \
-ORBDaemon &
machine1 \$ export
machine1 \$ deployer-corba-gnulinux -s demo.xml
machine2 \$ export
machine2 \$ ./demogui


OmniORB does not support the NameServiceIOR environment variable

machine1 \$ omniNames -start &
machine1 \$ deployer-corba-gnulinux -s demo.xml  
machine2 \$ ./demogui -ORBInitRef

Note that if you swap which machines run the deployer and demogui, then change the above to

machine1 \$ omniNames -start &
machine2 \$ deployer-corba-gnulinux -s demo.xml  -- \
machine1 \$ ./demogui 

Non-working DNS or you must use IP addresses

If you don't have DNS or you must use IP addresses for some reason.


machine1 \$ Naming_Service -m 0 -ORBDottedDecimalAddresses 1 \
-ORBListenEndpoints iiop:// -ORBDaemon &
machine1 \$ export NameServiceIOR=corbaloc:iiop:
machine1 \$ deployer-corba-gnulinux -s demo.xml -- -ORBDottedDecimalAddresses 1
machine2 \$ export NameServiceIOR=corbaloc:iiop:
machine2 \$ ./demogui -ORBDottedDecimalAddresses 1

For more information on the ORBListenEndPoints syntax and possibilities, see


machine1 \$ omniNames -start &
machine1 \$ deployer-corba-gnulinux -s demo.xml  
machine2 \$ ./demogui -ORBInitRef NameService=corbaloc:iiop:

And the reverse

machine1 \$ omniNames -start &
machine2 \$ deployer-corba-gnulinux -s demo.xml  -- \
-ORBInitRef NameService=corbaloc:iiop:
machine1 \$ ./demogui 


Certain distro's and certain CORBA versions will exhibit problems even with localhost only scenarios (demonstrated with OmniORB under Ubuntu Jackaloupe). If you can not connect to the name service running on the same machine, substitue the primary network interface's IP address for localhost in any NameService value.

For example, instead of

machine1 \$ omniNames -start &
machine2 \$ deployer-corba-gnulinux -s demo.xml 

or even

machine1 \$ omniNames -start &
machine2 \$ deployer-corba-gnulinux -s demo.xml  -- \
-ORBInitRef NameService=corbaloc:iiop:localhost:2809/NameService


machine1 \$ omniNames -start &
machine2 \$ deployer-corba-gnulinux -s demo.xml  -- \
-ORBInitRef NameService=corbaloc:iiop:

NB as of RTT v1.8.2 and OmniORB v4.1.0, programs like demogui (which use RTT::ControlTaskProxy::InitOrb() to initialize CORBA) do not support -ORBDottedDecimalAddresses (in case you try to use it).

Multi-homed machines

Computers that have multiple network interfaces present additional problems. The following is for omniORB (verified with a mix of v4.1.3 on Mac OS X, andv v4.1.1 on Ubuntu Hardy), for a system running a name server, a deployer, and a GUI. The example system has a wired subnet and a wireless subnet, and you have a mobile vehicle that has to communicate over the wireless subnet but it also has a wired interface.

The problem may appear as one of

  • The vehicle can not contact the name server when the wired interface is disconnected but it is up (NB on rare occasions, we've seen this even with the wired interface disconnected and down!)
  • Your GUI can connect to the deployer, but then locks up or throws a CORBA exception when trying to connect to certain remote Orocos items (we had this happen specifically for methods with parameters).

The solution is to forcibly specify the endPoint parameter to the name server. In the omniorb.cfg file on the computer running the name server, add (for the example networks above)

endPoint = giop:tcp:
where is the IP adrs of that computer. This forces the name server to publish end points on the wireless network first. Despite this, it will still publish the wired interface but it will come after the wireless. Specifying the endPoint parameter on the command line (instead of the config file) will not work, as then the name sever publishes the wired network first, and then the wireless network second.

If the above still does not work, then set the endPoint parameter in all computer's config files (note that the end point is the IP adrs of each computer, so it will be (say) for the computer running the name server and the deployer, and (say) for the computer running the GUI). This will force everyone onto the wireless network, instead of relying on what the name server is publishing.

To debug this problem see the debugging section below, but after starting the name server you will see it output its published endpoints (right after the configuration dump). Also, if you get the lockup then adding the debug settings will cause the GUI or deployer to output each message and what direction/IP it is going on. If they have strayed on to the wired network it will be visibly obvious.

NB we found that the clientTransportRule and serverTransportRule parameters had no affect on this problem.

NB the above solution works now matter which computer the name server is running on (ie with the deployer, or with the GUI).


Add the following to the omniorb.cfg file

dumpConfiguration = 1
traceLevel = 25
and get ready for lots of output.

See also