You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Philipp Suter <su...@adobe.com> on 2016/01/14 18:30:23 UTC
OAK-3884 for UDBBroadcaster
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
Re: OAK-3884 for UDBBroadcaster
Posted by Philipp Suter <su...@adobe.com>.
The patch actually fixes the test that was broadcasting to the loopback interface :)
Cheers,
Philipp
On 15/01/16 09:30, "ianboston@gmail.com on behalf of Ian Boston" <ianboston@gmail.com on behalf of ieb@tfd.co.uk> wrote:
>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, "ianboston@gmail.com on behalf of Ian Boston" <
>> ianboston@gmail.com on behalf of ieb@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
>> >>
>> >>
>> >>
>>
Re: OAK-3884 for UDBBroadcaster
Posted by Ian Boston <ie...@tfd.co.uk>.
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, "ianboston@gmail.com on behalf of Ian Boston" <
> ianboston@gmail.com on behalf of ieb@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
> >>
> >>
> >>
>
Re: OAK-3884 for UDBBroadcaster
Posted by Philipp Suter <su...@adobe.com>.
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, "ianboston@gmail.com on behalf of Ian Boston" <ianboston@gmail.com on behalf of ieb@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
>>
>>
>>
Re: OAK-3884 for UDBBroadcaster
Posted by Ian Boston <ie...@tfd.co.uk>.
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
>
>
>