Hi,
Sorry. I misunderstood your question.
The Serverfault question referenced in the Oak issue was about broadcasting
to the loopback address, which can't be done.
The patch looked like it was attempting to do that.
Best Regards
Ian
On 14 January 2016 at 20:48, Philipp Suter <su...@adobe.com> wrote:
> The patch is for unit tests “only”. It executes the unit tests on the
> first interface address that has the BROADCAST option already configured.
> Such the loopback interface is not taken into account.
>
> The test will fail if there is no interface address that has the BROADCAST
> option configured.
>
> All of that could also be solved differently, e.g. with a virtual network.
> I am not sure if that exists for unit testing.
>
> Cheers,
>
> Philipp
>
>
> On 14/01/16 19:41, "ianbos...@gmail.com on behalf of Ian Boston" <
> ianbos...@gmail.com on behalf of i...@tfd.co.uk> wrote:
>
> >Hi,
> >
> >Does the patch work ?
> >
> >According to the answer in the serverfault article referenced in OAK-3884
> >it should not
> >
> >I tried the pattern referenced on OSX using nc and it doesn't work. The
> >original poster seems to think it works, but those answering disagree and
> >the posted wasn't able to tell them which kernel it worked on.....
> >
> >
> >"The "solution" you are asking for does not exist (or at least *should not
> >work*) on any platform unless the loopback interface supports BROADCAST
> (as
> >can be determined by the flags field in ifconfig) -- The platform(s) you
> >are talking about *do not advertise support for broadcasting on the
> >loopback interface*, therefore you cannot do what you're asking."
> >
> >
> >There are some other less complimentary comments.
> >
> >It might be possible, with root access to the test machine, to setup
> >several tun interfaces, connected to a bridge to create a virtual network
> >on the same machine. You can do the same with multiple docker hosts on the
> >same machine.... but all of that requires some setup that a Java process
> >isnt going to be able to do.
> >
> >----
> >
> >
> >
> >For a non loopback network you should not try and work out the broadcast
> >address. IIRC you should set the broadcast flag on the UDP packet. (I
> >assume UDB == UDP ?).
> >
> >I assume you are doing something like:
> >
> > socket = new DatagramSocket(8888, InetAddress.getByName("0.0.0.0"));
> > socket.setBroadcast(true);
> >
> >
> >Hosts on the same subnet will have the same network mast, otherwise they
> >are not on the same subnet. All sorts of things will start to fail. eg if
> >some are /24 and some are /25 all the broadcasts on the /25 subnet will be
> >directed at the .127 host on the /24 subnet. (I haven't tried to see what
> >a switch does with 2 overlapping and misconfigured subnets.).
> >
> >
> >
> >HTH
> >Best Regards
> >Ian
> >
> >
> >
> >
> >
> >On 14 January 2016 at 17:30, Philipp Suter <su...@adobe.com> wrote:
> >
> >> Hi
> >>
> >> I added a small patch to https://issues.apache.org/jira/browse/OAK-3884
> >> that could fix the broadcast unit tests for UDBBroadcaster. It seems the
> >> loopback interface is not allowing broadcasting on *NIX systems. The
> >> broadcasting IP has to be found dynamically for a test execution.
> >>
> >> Interesting next step: How could this be configured dynamically within a
> >> clustered set-up? It needs an agreement among all cluster members to use
> >> the same network mask.
> >>
> >> Cheers,
> >> Philipp
> >>
> >>
> >>
>
