Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of alexei.zakharov@gmail.com
 designates 66.249.92.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=eNxo3IjvH5yw4WH1A60g7G4r5x3ZnmYTkcOTszZWPDSDbjytGGqWj0J1EPol2BOHqGDMM+nRE4NFSu1d3MLkOUG4NwTtKtGFcEMlewjZGhDCTKDkbKHWt1fK6Kh7KZc/VCMx0n7rIUZaQnBKUf3CWD2bIjQgWORxVXLy8mkOE6s=
Message-ID: <2c9597b90706050247q528fc6c4m6a7ce8714c43866b@mail.gmail.com>
Date: Tue, 5 Jun 2007 13:47:48 +0400
From: "Alexei Zakharov" <alexei.zakharov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test
In-Reply-To: <211709bc0706042043y1d94d534kc4f65b9fc5c9b2b3@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20070602232502.4978.qmail@minotaur.apache.org>
	 <2c9597b90706030748g636ff67du64ee520a8c1831fb@mail.gmail.com>
	 <211709bc0706031904s30ffacaclb9cd15a32e6e17a0@mail.gmail.com>
	 <4663DD5D.2030102@gmail.com>
	 <211709bc0706042043y1d94d534kc4f65b9fc5c9b2b3@mail.gmail.com>

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 <wuyuehao@gmail.com>:
> Another way is to restrict the multicast ip address we used in our test.
>
> On 6/4/07, Tim Ellison <t.p.ellison@gmail.com> 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