Bug 1112

Accepted, we probably need to change the interfaces to the RtecUDPAdmin objects 
to fix this.

Just capturing some email discussion:

>      DESCRIPTION:
> 
>      If I federate event channels using the UDP/mcast classes
>      and only connect wildcard consumers (ACE_EC_EVENT_ANY),
>      then the TAO_ECG_Mcast_EH class never queries my address
>      server and no addresses are ever listened to.  This all
>      adds up to no events received via multicast.

	Right.

>      To some extent I realize that I am probably using things in
>      a different way than the author of the code intended, but it
>      is not too difficult of a change to get this working although
>      I am not sure if there are other effects of my change on
>      existing systems.

	Hmmm, I do not think your solution would work, see below....

>        if (0 <= header.type && header.type < ACE_ES_EVENT_UNDEFINED)
>          {
>             continue;
>          }
> 
>      to
> 
>        if (ACE_ES_EVENT_ANY < header.type &&
>            header.type < ACE_ES_EVENT_UNDEFINED)
>          {
>             continue;
>          }
> 
>      basically this ensures that the headers with the type of "any"
>      are passed to the receiver and eventually the address server.

	This is not enough, you see, there is no single multicast group that 
the consumer-side event service should subscribe to get all the events, 
however, the RtecUDPAdmin interfaces only provide interfaces to return a single 
multicast group for each event type.

	Naturally you could prescribe that a "magic" multicast group be used 
for all wildcard traffic, but then you run into problems because your consumers 
may subscribe to both specific event types and wildcards, potentially receiving 
the same event from two different multicast groups, essentially duplicating the 
event.

> Does anybody have an opinion on this change?

	Obviously I do, but then again, I've been known to have opinions when I 
shouldn't :-)

> I seem to remember that the RTING people use these 
> federations; anybody out there care to comment?

	I think we need to come up with a more systematic approach to deal with 
wildcards in the subscriptions.  For example, the RtecUDPAdmin may need to 
provide an iterator interface to return *multiple* multicast groups for each 
subscription.

						HTH

Some ideas on how an RtecUDPAdmin module should look like for this:

/**
 * @namespace RtecUDPAdmin
 *
 * @brief Define the data structures and interfaces used by UDP-based
 *   gateways
 */
module RtecUDPAdmin
{
  /**
   * @struct UDP_Addr
   *
   * @brief Represent a UDP SAP.
   */
  struct UDP_Addr
  {
    /// The IP address
    unsigned long ipaddr;
    /// The UDP port
    unsigned short port;
  };

  typedef sequence<UDP_Addr> UDP_Addr_Sequence;

  /**
   * @interface AddrServer
   *
   * @brief Defines a interface to configure the mapping between
   *   events and multicast groups (or UDP broadcast or UDP unicast)
   *   addresses.
   */
  interface AddrServer
  {
    /// Get the UDP address give the event header
    /**
     * @param header The event header, used to fetch the type and
     *   source of the event
     * @param addr Return the address used for the given event type
     *
     * @throw BAD_PARAM if the header parameter is a wildcard address
     */
    void get_addr (in RtecEventComm::EventHeader header,
                   out UDP_Addr addr);
  };

  interface Address_Iterator;

  /**
   * @interface Wildcard_Address_Server
   *
   * @brief Extend the basic AddrServer interface to support wildcard
   * addresses.
   */
  interface Wildcard_Address_Server : AddrServer
  {
    /// Return all the addresses assigned to transport events with a
    /// given event header.
    /**
     * @param header The prototype header that the application wants
     *        to send or receive.
     * @param max_addresses Limit the number of addresses that the
     *        application wants to receive in the return argument.
     *        If 0 the server selects the maximum number of addresses.
     * @param iterator Returns a non-nil iterator if the complete list
     *        of addresses was too big for the return parameter.
     * @return The initial group of addresses required to support @c
     *         header.
     */
    UDP_Addr_Sequence
      get_all_addresses (in RtecEventComm::EventHeader header,
			 in unsigned long max_addresses,
			 out Address_Iterator iterator);
  };

  interface Address_Iterator
  {
    /// Return the next group of addresses
    /**
     * @param max_addresses Limit the number of addresses that the
     *        application wants to receive in the return argument.
     *        If 0 the server selects the maximum number of addresses.
     *
     * @return The next group of addresses.  If the number of
     *         addresses is smaller than @c max_addresses the
     *         application can assume that no more addresses are
     *         available and that the iterator has been destroyed.
     *         In the unlikely event that the total number of
     *         addresses is a multiple of @c max_addresses the last
     *         call to this operation returns an empty sequence.
     *
     * @return OBJECT_NOT_EXIST The iterator may be proactively
     *         destroyed by the server to conserve resources.
     */
    UDP_Addr_Sequence next (in unsigned long max_addresses);

    /// Destroy the iterator
    /**
     * The application should call this method to discard an iterator
     * before it completed the iteration.
     */
    void destroy ();
  };
};

#endif /* TAO_RTEC_UDP_ADMIN_IDL */

I will never have time to work on these bugs.  Returning them to the TAO support
pool.

Accept for tao-support

Marina, is this maybe fixed in all the ATD stuff I integrated?

Johnny, this issue has not been addressed in ATD's changes.

Added myself as CC. In the IIOP Gateway the problem with source 0 and type = 0 
also exists. There when type is 0, it is also not subscribed when source is 0, 
no problem when source is a different number.

Checked the code, the <= is now a < in the latest version of the code.