Handling of IPv6 mcast_addrs

[Bela Ban]

In 2.8, we changed the way IP addresses are handled. Below, I want to
briefly describe an issue I ran into, and the corresponding fix, but
wanted to solicit feedback, as this will change things a bit.

The type of a stack (IPv4, IPv6 or dual) is determined by the installed
stacks and the system props java.net.preferIPv4Stack (default: false)
and java.net.preferIPv6Addresses (default: false).

#1 If only preferIPv4Stack is set, then we use IPv4.

#2 If only preferIPv6Addresses is set, we use IPv6.

#3 If both are set, we use IPv4.

#4 If neither is set, we use IPv6 (!)


Now if we have a config such as

CONFIG-1: <UDP mcast_addr="232.5.5.5" ... /> // IPv4 mcast_addr
CONFIG-2: <UDP mcast_addr="ff0e::8:8:8" ... /> // IPv6 mcast_addr

, then the following can happen (assuming we have both types of stack
available):

We run without any java.net.preferXXX props:

    * The stack is IPv6 by default
    * CONFIG-1 will fail because we passed an IPv4 address to an IPv6 stack

We run with preferIPv4Stack=true:

    * The stack is IPv4
    * CONFIG-2 will fail as we're running with an IPv4 stack

Both props are set:

    * CONFIG-2 will fail, same as above

*So my proposal is to remove all properties from the shipped XML
configurations that have IP addresses, e.g. bind_addr (not used anywhere
though) and UDP.mcast_addr.*

This will allow for the case where no java.net.preferXXX props are set;
it will not fail (it currently does fail !) because we're picking a
stack type compliant (IPv6) mcast_addr.

I assume a lot of folks trying out JGroups for the first time don't
bother even reading the documentation and will *not* set a
java.net.preferXXX system property, and would therefore run into an
exception when using a current sample config file, e.g. udp.xml. This
won't happen with the proposed change.

Folks who want to force a specific stack type and use specific IP
addresses, have to (1) define the right values in the XML config (or
pass them to JGroups via system props) and (2) possibly set a
java.net.preferXXX system property (not needed if the default is what a
user wants).

What do people think ? Feedback appreciated !


--
Bela Ban
Lead JGroups / Clustering Team
JBoss


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Javagroups-development mailing list

[vivek sar]

Hello Bela,

    Just a clarification,

1) When you say, "remove all properties from the shipped XML", do you
mean they won't be supported in the protocol stack anymore or just
won't be part of default xml files that come with JGroups?

2) We are using TCP /w Gossip Router and have the ip addresses
specified at two places - bind_addr and initial_hosts - would that
change?

Just another comment, wouldn't it be better if we default to IPv4
(looks like the majority of cases) and add a comment in the shipped
xml for IPv6.

Thanks,
-vivek

On Tue, Oct 27, 2009 at 9:28 AM, Bela Ban <belaban@...> wrote:

> In 2.8, we changed the way IP addresses are handled. Below, I want to
> briefly describe an issue I ran into, and the corresponding fix, but
> wanted to solicit feedback, as this will change things a bit.
>
> The type of a stack (IPv4, IPv6 or dual) is determined by the installed
> stacks and the system props java.net.preferIPv4Stack (default: false)
> and java.net.preferIPv6Addresses (default: false).
>
> #1 If only preferIPv4Stack is set, then we use IPv4.
>
> #2 If only preferIPv6Addresses is set, we use IPv6.
>
> #3 If both are set, we use IPv4.
>
> #4 If neither is set, we use IPv6 (!)
>
>
> Now if we have a config such as
>
> CONFIG-1: <UDP mcast_addr="232.5.5.5" ... /> // IPv4 mcast_addr
> CONFIG-2: <UDP mcast_addr="ff0e::8:8:8" ... /> // IPv6 mcast_addr
>
> , then the following can happen (assuming we have both types of stack
> available):
>
> We run without any java.net.preferXXX props:
>
>    * The stack is IPv6 by default
>    * CONFIG-1 will fail because we passed an IPv4 address to an IPv6 stack
>
> We run with preferIPv4Stack=true:
>
>    * The stack is IPv4
>    * CONFIG-2 will fail as we're running with an IPv4 stack
>
> Both props are set:
>
>    * CONFIG-2 will fail, same as above
>
> *So my proposal is to remove all properties from the shipped XML
> configurations that have IP addresses, e.g. bind_addr (not used anywhere
> though) and UDP.mcast_addr.*
>
> This will allow for the case where no java.net.preferXXX props are set;
> it will not fail (it currently does fail !) because we're picking a
> stack type compliant (IPv6) mcast_addr.
>
> I assume a lot of folks trying out JGroups for the first time don't
> bother even reading the documentation and will *not* set a
> java.net.preferXXX system property, and would therefore run into an
> exception when using a current sample config file, e.g. udp.xml. This
> won't happen with the proposed change.
>
> Folks who want to force a specific stack type and use specific IP
> addresses, have to (1) define the right values in the XML config (or
> pass them to JGroups via system props) and (2) possibly set a
> java.net.preferXXX system property (not needed if the default is what a
> user wants).
>
> What do people think ? Feedback appreciated !
>
>
> --
> Bela Ban
> Lead JGroups / Clustering Team
> JBoss
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> javagroups-users mailing list
> javagroups-users@...
> https://lists.sourceforge.net/lists/listinfo/javagroups-users
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Javagroups-development mailing list

[Bela Ban]

vivek sar wrote:
> Hello Bela,
>
> Just a clarification,
>
> 1) When you say, "remove all properties from the shipped XML", do you
> mean they won't be supported in the protocol stack anymore or just
> won't be part of default xml files that come with JGroups?

I meant to remove mcast_addr from all default XML config files shipped
with JGroups. Of course, the property UDP.mcast_addr will still be
supported.

> 2) We are using TCP /w Gossip Router and have the ip addresses
> specified at two places - bind_addr and initial_hosts - would that
> change?

Hmm... I might remove bind_addr, too. But I think I'm going to leave
TCPPING.initial_hosts and TCPGOSSIP.initial_hosts, so that if folks use
the default there will be an exception and the correct IP addresses have
to be entered.

> Just another comment, wouldn't it be better if we default to IPv4
> (looks like the majority of cases) and add a comment in the shipped
> xml for IPv6.

I agree. The issue is that the JDK itself defaults to IPv6 unless
java.net.preferIPv4Stack is set. Originally, I thought I could take a
look at the provided IP addresses, and set the stack type accordingly by
setting a java.net.preferXXX system property. However, apparently this
only works at JVM startup time and cannot be changed dynamically...

--
Bela Ban
Lead JGroups / Clustering Team
JBoss


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Javagroups-development mailing list

[Vladimir Blagojevic-2]

I agree with your proposal and I think Mr. Andiamo would agree as well :)

On 09-10-27 12:28 PM, Bela Ban wrote:

> In 2.8, we changed the way IP addresses are handled. Below, I want to
> briefly describe an issue I ran into, and the corresponding fix, but
> wanted to solicit feedback, as this will change things a bit.
>
> The type of a stack (IPv4, IPv6 or dual) is determined by the installed
> stacks and the system props java.net.preferIPv4Stack (default: false)
> and java.net.preferIPv6Addresses (default: false).
>
> #1 If only preferIPv4Stack is set, then we use IPv4.
>
> #2 If only preferIPv6Addresses is set, we use IPv6.
>
> #3 If both are set, we use IPv4.
>
> #4 If neither is set, we use IPv6 (!)
>
>
> Now if we have a config such as
>
> CONFIG-1:<UDP mcast_addr="232.5.5.5" ... />  // IPv4 mcast_addr
> CONFIG-2:<UDP mcast_addr="ff0e::8:8:8" ... />  // IPv6 mcast_addr
>
> , then the following can happen (assuming we have both types of stack
> available):
>
> We run without any java.net.preferXXX props:
>
>      * The stack is IPv6 by default
>      * CONFIG-1 will fail because we passed an IPv4 address to an IPv6 stack
>
> We run with preferIPv4Stack=true:
>
>      * The stack is IPv4
>      * CONFIG-2 will fail as we're running with an IPv4 stack
>
> Both props are set:
>
>      * CONFIG-2 will fail, same as above
>
> *So my proposal is to remove all properties from the shipped XML
> configurations that have IP addresses, e.g. bind_addr (not used anywhere
> though) and UDP.mcast_addr.*
>
> This will allow for the case where no java.net.preferXXX props are set;
> it will not fail (it currently does fail !) because we're picking a
> stack type compliant (IPv6) mcast_addr.
>
> I assume a lot of folks trying out JGroups for the first time don't
> bother even reading the documentation and will *not* set a
> java.net.preferXXX system property, and would therefore run into an
> exception when using a current sample config file, e.g. udp.xml. This
> won't happen with the proposed change.
>
> Folks who want to force a specific stack type and use specific IP
> addresses, have to (1) define the right values in the XML config (or
> pass them to JGroups via system props) and (2) possibly set a
> java.net.preferXXX system property (not needed if the default is what a
> user wants).
>
> What do people think ? Feedback appreciated !
>
>
>    

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Javagroups-development mailing list

[Brian Stansberry-4]

Makes sense to me as well. Only thing I'd add is that people use the  
stacks that ship with JGroups as a form of documentation, so if you  
remove stuff that folks are likely to add back in their configs, make  
sure the docs cover the ground well, e.g. have examples.

On Oct 28, 2009, at 10:47 PM, Vladimir Blagojevic wrote:

> I agree with your proposal and I think Mr. Andiamo would agree as  
> well :)
>
> On 09-10-27 12:28 PM, Bela Ban wrote:
>> In 2.8, we changed the way IP addresses are handled. Below, I want to
>> briefly describe an issue I ran into, and the corresponding fix, but
>> wanted to solicit feedback, as this will change things a bit.
>>
>> The type of a stack (IPv4, IPv6 or dual) is determined by the  
>> installed
>> stacks and the system props java.net.preferIPv4Stack (default: false)
>> and java.net.preferIPv6Addresses (default: false).
>>
>> #1 If only preferIPv4Stack is set, then we use IPv4.
>>
>> #2 If only preferIPv6Addresses is set, we use IPv6.
>>
>> #3 If both are set, we use IPv4.
>>
>> #4 If neither is set, we use IPv6 (!)
>>
>>
>> Now if we have a config such as
>>
>> CONFIG-1:<UDP mcast_addr="232.5.5.5" ... />  // IPv4 mcast_addr
>> CONFIG-2:<UDP mcast_addr="ff0e::8:8:8" ... />  // IPv6 mcast_addr
>>
>> , then the following can happen (assuming we have both types of stack
>> available):
>>
>> We run without any java.net.preferXXX props:
>>
>>     * The stack is IPv6 by default
>>     * CONFIG-1 will fail because we passed an IPv4 address to an  
>> IPv6 stack
>>
>> We run with preferIPv4Stack=true:
>>
>>     * The stack is IPv4
>>     * CONFIG-2 will fail as we're running with an IPv4 stack
>>
>> Both props are set:
>>
>>     * CONFIG-2 will fail, same as above
>>
>> *So my proposal is to remove all properties from the shipped XML
>> configurations that have IP addresses, e.g. bind_addr (not used  
>> anywhere
>> though) and UDP.mcast_addr.*
>>
>> This will allow for the case where no java.net.preferXXX props are  
>> set;
>> it will not fail (it currently does fail !) because we're picking a
>> stack type compliant (IPv6) mcast_addr.
>>
>> I assume a lot of folks trying out JGroups for the first time don't
>> bother even reading the documentation and will *not* set a
>> java.net.preferXXX system property, and would therefore run into an
>> exception when using a current sample config file, e.g. udp.xml. This
>> won't happen with the proposed change.
>>
>> Folks who want to force a specific stack type and use specific IP
>> addresses, have to (1) define the right values in the XML config (or
>> pass them to JGroups via system props) and (2) possibly set a
>> java.net.preferXXX system property (not needed if the default is  
>> what a
>> user wants).
>>
>> What do people think ? Feedback appreciated !
>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> javagroups-users mailing list
> javagroups-users@...
> https://lists.sourceforge.net/lists/listinfo/javagroups-users

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Javagroups-development mailing list