Tim Ellison wrote:
> Huh? What is that machine? and why are our tests dependent upon it? > Shouldn't we fix the test instead?
Well, it is not a "machine" in the strict sense. This kind of IPv4 addresses (239.0.0.0-239.255.255.255) are known as "Administratively Scoped IP Multicast" Class-D address. I am not an expert in topology of IPv4 networks. However, AFAIU this is like 192.168.x.x address for unicast addresses. There is no need for it to be unique across Internet, it is local to the network where it is used. Packets sent to this address are handled by a clever router (or whatever) and redirected to registered listeners - hosts that have registered itself in the multicast group formed around this address via IGMP (Internet Group Management Protocol). I can be not 100% correct in my explanation. For more reliable and complete information about multicast addresses please see [1] and [2]. Tony Wu wrote:
Another way is to restrict the multicast ip address we used in our test.
Yes, I agree. As we have already discussed many times for similar issues, we may create a special property to customize multicast address we use in tests or determine it dynamically somehow via Support.getMulticastAddress(). [1] RFC-3171 "IANA Guidelines for IPv4 Multicast Address Assignments", http://www.ietf.org/rfc/rfc3171.txt [2] RFC-2365 "Administratively Scoped IP Multicast", http://www.ietf.org/rfc/rfc2365.txt Thanks. 2007/6/5, Tony Wu <[EMAIL PROTECTED]>:
Another way is to restrict the multicast ip address we used in our test. On 6/4/07, Tim Ellison <[EMAIL PROTECTED]> wrote: > Tony Wu wrote: > > This test fails because the address 239.255.2.3 is baned by firewall. > > I've added it to accpet list. > > Huh? What is that machine? and why are our tests dependent upon it? > Shouldn't we fix the test instead? > > Regards, > Tim -- Tony Wu China Software Development Lab, IBM
-- Alexei Zakharov, Intel ESSD
