[Ace-users] [ace-users] Subject: Trading services doesn't work properly when amultihomed Mac client is configured to use an ethernet portconnected to a private network.

Alex Sheh ASHEH at euphonix.com
Fri Oct 12 18:26:30 CDT 2007

I've recompiled ACE+TAO with my own syslog logging and I've discovered a
couple of things.  The below observations were made when I called
orb_init with the following arguments on MacOSX (same scenario as stated
in the below form).
	-ORBPreferredInterfaces ""
-ORBEnforcePreferredInterfaces yes.

The brief summary of what I found is that IIOP and SCIOP both implement
-ORBEnforcePreferredInterfaces, however UIPMC ignores the preferred
interfaces argument and instead always configures UIPMC connections
using a wildcard address.  My questions are, is my
analysis/understanding correct, and if so, is there a plan to implement
the -ORBEnforcePreferredInterfaces option for UIPMC in the future?  If
my understanding is flawed, please let me know what steps to take to
make multihomed nic selection work for UIPMC.  Thanks!

Below is the long detailed account,

TAO_IIOP_Profile::decode_profile( ) and
TAO_SCIOP_Profile::decode_profile both call TAO_ORB_Parameters::
preferred_interfaces( ) to retrieve the -ORBPreferredInterfaces
argument.  Both TAO_IIOP_Endpoint and TAO_SCIOP_Endpoint then use the
-ORBPreferredInterface argument to optionally enforce the preferred
interfaces policy.  However, I don't see
TAO_UIPMC_Profile::decode_profile doing anything with the 
-ORBPreferredInterface argument, instead I see that UIPMC connections
are always configured to use the wildcard address.

For each IP address in the -ORBPreferredInterface list,
TAO_IIOP_Endpoint chains a list of TAO_IIOP_Endpoint objects off of
itself (each is a duplicate of this object, with the preferred_path
member's host string set to a particular IP address from the
-ORBPreferredInterface list).  TAO_IIOP_Connector::make_connection( )
then calls TAO_IIOP_Endpoint ::preferred_network( ) to retrieve the
preferred interface, and creates an ACE_INET_Addr local addr with the
preferred interface's IP address.  The local_addr is then used to open
an IIOP connection with
ACE_SOCK_CONNECTOR>::connect( ).

TAO_SCIOP_Endpoint does something similar to create an SCIOP connection
with a local address corresponding to the -ORBPreferredInterfaces

TAO_UIPMC_however does not parse the -ORBPreferredInterface argument in
decode_profile, etc.  Instead, TAO_UIPMC_Connector::make_connection( )
directly configures TAO_UIPMC_Connection_Handler, setting its local
address variable to the wildcard address, local_addr =
ACE_Addr::sap_any.  So rather than configuring the UIPMC connection to
use the preferred interfaces specified by -ORBPreferredInterfaces, the
wildcard address is always used.

The fact that UIPMC ignores -ORBPreferredInterfaces and always uses the
wildcard address, explains the behavior that I'm seeing while using
Trading Services on MacOSX.  The below comments relating to the
IP_MULTICAST_IF multicast socket option are taken from "UNIX Network
Programming, Volume 1" (Richard Stevens),

	"If the value specified is INADDR_ANY for IPv4 or is a interface
index of 0 for IPv6, this removes 	any interface previously
assigned by this socket option and the system will choose the interface
each 	time a datagram is sent."

	"Berkeley-derived kernels choose the default interface for an
outgoing multicast datagram by 	searching the normal IP routing table
for a route to the destination multicast address, and the
corresponding interface is used."

When I look at the routing table using "route get"
(multicast address, I see different contents depending on
my Mac's physical ethernet port configuration.  When I am only connected
to the private network, the routing table shows a route to
via the private network port.  When I am connected to both the private
network and the public network, the routing table shows a route to via the public network port.  According to Richard Stevens,
when the IP_MULTICAST_IF socket option is set to the wildcard address,
the corresponding interface for the multicast route is selected for
outgoing multicast datagrams.  This explains why, when my Mac is
connected to both the private and public networks, the multicast Trading
Service offers sent by my Mac are not received by the server computer.
The server computer lives on the private network, but my Mac is sending
the UIPMC outgoing multicast datagrams through its public network port.

Thanks for the help,
- Alex 

-----Original Message-----
From: Johnny Willemsen [mailto:jwillemsen at remedy.nl] 
Sent: Friday, October 12, 2007 6:34 AM
To: Alex Sheh; ace-users at cs.wustl.edu
Subject: RE: [ace-users] Subject: Trading services doesn't work properly
when amultihomed Mac client is configured to use an ethernet
portconnected to a private network.

Thanks for using the PRF form. Maybe the order in which the interfaces
are returned can be different. Try to run things with ORBDebugLevel 10
and see what you get for output.
Johnny Willemsen
Remedy IT
Postbus 101
2650 AC  Berkel en Rodenrijs
The Netherlands
www.theaceorb.nl / www.remedy.nl 

*** Integrated compile and test statistics see
http://scoreboard.theaceorb.nl <http://scoreboard.theaceorb.nl/>  ***
*** Commercial service and support for ACE/TAO/CIAO             ***
*** See http://www.theaceorb.nl/en/support.html                 *** 


	From: ace-users-bounces at cse.wustl.edu
[mailto:ace-users-bounces at cse.wustl.edu] On Behalf Of Alex Sheh
	Sent: Tuesday, October 09, 2007 12:15 AM
	To: ace-users at cs.wustl.edu
	Subject: [ace-users] Subject: Trading services doesn't work
properly when amultihomed Mac client is configured to use an ethernet
portconnected to a private network.
	    ACE VERSION: 5.5
	 Intel, MacOSX 10.4.10
	    TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
	 Windows XP
	    THE $ACE_ROOT/ace/config.h FILE
	    THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE
	    (used by MPC when you generate your own makefiles):
	 Trading services, multihomed Mac client on a private network
	        COMPILATION no
	        LINKING? no
	            On Unix systems, did you run make realclean first?
	        EXECUTION? yes
	        OTHER (please specify)?
	         Trading services doesn't work properly when a
multihomed Mac client is configured to use an ethernet port connected to
a private network.  The client ORB is configured using
-ORBPreferredInterfaces to use an ethernet port that is connected to a
private network, and the other ethernet port is connected to a public
network.  The target host exists on the private network and queries the
trading service, but it is not able to see the multihomed client.  This
works fine with a multihomed PC client.
	         I have code that is using a trading service between
computers, so that a group of workstation computers can notify a central
computer that they exist.  I would like to configure the system so that
the client workstations and the central computer communicate via trading
services on a private network.  Additionally, the client workstations
are multihomed, with an ethernet port connected to the private network
and another ethernet port connected to the public network for internet
	         With a PC client, the above system configuration works
fine.  The target host is able to "see" the multihomed PC client on the
private network via a trading service query.  The PC's client ORB is
configured with the following ORB_init interface argument, specifying
that the private nework ethernet port should be used for trading
services (didn't even need to pass any preferred interface arguments),
	         -ORBEndpoint iiop:://
	         With a Mac client, however, the above system
configuration does not work.  When the target host queries the trading
service, it is not able to see the multihomed Mac client on the private
network.  However, if I unplug the public network ethernet cable from
the multihomed Mac client (I suppose, effectively disabling that
interface on the Mac), then the target host is suddenly able to "see"
the multihomed Mac client on the private network via a trading service
query.  The Mac's client ORB is configured with the following ORB_init
interface arguments (I even added the preferred interface arguments but
things still don't work)
	         -ORBEndpoint iiop:://
-ORBPreferredInterfaces -ORBEnforcePreferredInterfaces yes
	         Could someone explain to me why the above system
configuration, with multihomed Mac clients using trading services on a
private network, does not work?  Why does the PC work okay and not the
Is there something additional that I should be doing to get the Mac
client working?
	          Thanks for you help,
	 Run my code.

More information about the Ace-users mailing list