Just some clarifications...

TAO's TaggedComponent IIOP 1.1 implementation currently doesn't support the
TAG_ALTERNATE_IIOP_ADDRESS component needed for IIOP 1.2 compliance.  Once TAO
1.0 is released, and we start adding IIOP 1.2 features to TAO, then we can
implement support for this feature.

Note that their doesn't appear to be anything in the spec about whether or not
duplicate alternate addresses are allowed.

TAO supports multi-homed hosts, using multiple -ORBendpoint options; there is no
way to *automatically* use all the interfaces, but that is really minor.
Since the ALTERNATE_IIOP_ADDRESS component is not standard in GIOP 1.1 we cannot
rely on it until we implement GIOP 1.2 (a major task on its own).
I suggest that we fix this after 1.0

Maybe Ossama and Irfan can take care of this problem, because they have a better
idea of what the real issue is (IMHO it should be closed until GIOP 1.2 is
implemented).

I'll work on this enhancement once Carlos et al implement support for IIOP 1.2.

Deferred until GIOP 1.2 is implemented in TAO.

I've got fix ready to be committed to the CVS repository.  The implementation
doesn't rely on GIOP 1.2, specifically the ALTERNATE_IIOP_ADDRESS component.  A
default IIOP endpoint option (-ORBEndpoint iiop://) will cause an endpoint to
created on each network interface.

One thing to note is that a bad host table causes problems, but this problem
isn't specific to this fix.  It is a problem for TAO, but it is *not* a problem
with TAO.

Mine

Support for hosts with multiple network interfaces has been checked in to the
repository.  A profile will be created for each detected network interface.  The
loopback interface will be ignored unless it is the only interface available on
the host.  Each of those profiles will be encoded in to the generated IOR.

See:

  ChangeLogTag:Fri Feb 25 08:59:59 2000  Ossama Othman  <ossama@uci.edu>

for details.

The support that was added does not rely on IIOP 1.2.  Once IIOP 1.2 support is
implemented, we'll be able to take advantage of the alternate address tag
provided by it.

Our RT CORBA team has added the proprietary equivalent to the standard alternate
address tagged component.  The standard alternate address tagged component
implementation should leverage the support added by the RT CORBA team.  However,
RT CORBA support should not be necessary to use alternate address tagged
components.

This bug was fixed some time ago:

Fri Jun 10 07:51:36 2005  Phil Mesnier  <mesnier_p@ociweb.com>

        * docs/Options.html:
        * tao/IIOP_Acceptor.cpp:
        * tao/IIOP_Profile.cpp:
        * tao/IIOP_Profile.h:
        * tao/ORB_Core.cpp:
        * tao/Tagged_Components.cpp:
        * tao/Tagged_Components.h:
        * tao/params.cpp:
        * tao/params.h:
        * tao/params.i:
        * tao/PortableServer/Default_Acceptor_Filter.cpp:
        * tests/AlternateIIOP:
        * utils/catior/catior.cpp:

          Added support for TAG_ALTERNATE_IIOP_ADDRESS to combine many
          endpoints into a single profile when not using RTCORBA. This may
          be overridden by using the ORB_init argument
          -ORBUseSharedProfiles 0. It is enabled by default. Unlike the
          TAO-specific TAO_TAG_ENDPOINTS, the TAG_ALTERNATE_IIOP_ADDRESS
          component contains a single host:port pair, but many such
          components may be added to a profile to carry as many endpoints
          as required.

and it was further refined:

Thu Jun 30 09:50:46 2005  Phil Mesnier  <mesnier_p@ociweb.com>

        * tao/IIOP_Profile.cpp:
        * tao/IIOP_Profile.h:
        * tao/Profile.cpp:
        * tao/Profile.h:
        * tao/PortableServer/Default_Acceptor_Filter.cpp:
          This restores the behavior of IIOP_Profile::encode_endpoints so
          that it always creates only TAO_TAG_ENDPOINT component.
          Initially, the new TAG_ALTERNATE_IIOP_ADDRESS support was added
          to this method, with an internal test if the endpoint priority
          was TAO_INVALID_PRIORITY or not. If it was not, both kinds of
          tagged components were created, if the priority was invalid,
          only the new tagged component was created. But this causes
          trouble for RT_CORBA with multiple nics. It also generates
          redundant components.

          A new method, encode_alternate_endpoints is added to support the
          generation of combined endpoints in non-RT ORBs. This new method
          is called from Default_Acceptor_Filter.cpp. The base TAO_Profile
          supplies a null implementation of encode_alternate_endpoints so
          that existing, non-IIOP profiles don't have to be altered.

        * tao/params.cpp:
          To address the issue raised by bugzilla #2173, I've set the
          default for using shared profiles (non-RT) to 0. This avoids a
          side-effect of making shared profiles with endpoints that do not
          have a priority set in an RT environment.

        * tests/AlternateIIOP/run_test.pl:
          Add an explicit -ORBUseSharedProfile 1 to the server.

Marking this bug resolved:fixed.