[jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics uses hard-coded IPv4 multicast address

[ https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugi... ] Richard Achmatowicz commented on JGRP-978: ------------------------------------------ Bela Here are my thoughts on this issue: The problem ----------- A user starts up jgroups, possibly specifying values for the some of the IP addresses which JGroups makes use of: * UDP: bind_addr, mcast_addr, diagnostics_addr * TCP: bind_addr, initial_hosts The user can specify zero or more such values, relying on defaults if values are left unspecified. Possible Requirements ------------ 1. We want to make sure that the complete set of values is specified, before any sockets are created. 2. We assume that a mixed configuration of IPv4 and IPv6 addresses in one stack is unwanted. 3. The decision to use a set of addresses must agree with the stacks available (or preferred in the case of dual stack availability) on the host. Design for a solution (for UDP/TCP layers) --------------------- Idea: A. define defaults for all required IP address values above for both IPv4 and IPv6 B. at stack initialization, collect up all the values specified by the user (after parameters processing in UDP/TCP) C. - if one or more values specified: D. - check if a consistent set of either IPv4 or IPv6 addresses E. - if not consistent set, raise exception and don't start stack F. - if consistent set, set useIPv4/useIPv6 variable to record the consistency, and complete the set with appropriate defaults // NOTE: this takes the user's decision on IPv4 vs IPv6 and goes with it, making no checks to see if the // chosen stack is available on the machine. The user may receive Socket exceptions is the stack // is not available, or if the stack preference (java.net.preferIPv4Stack) is set differently from the users choice // on a dual stack machine. G. - if zero values specified: H. - check to see which stacks are available on the machine (by enumerating all network interfaces and for each, checking if IPv4 or IPv6 addresses are defined) and set the values isIPv4Available/isIPv6Available I. - if only IPv4 is available, set useIPv4=true and complete the set of approproate defaults J. - if only IPv6 is available, set useIPv6=true and complete set of appropriate defaults K. - if both IPv6 and IPv4 are available, use JVM property java.net.preferIPv4Stack value to decide which stack to use and complete the set of appropriate defaults // NOTE: this checks the presence of the IPv4 and IPv6 stacks, and chooses one, taking into account the JVM stack preference // setting. This determines uniquely whether IPv4 or IPv6 sockets will be created by the JVM. This may result in IPv4 addresses being // used with IPv6 sockets (and so IPv4-mapped addresses used internally). L. before sockets are created, we end up with the following values set: useIPv4/useIPv6, which indicates which IP stack was chosen, based on user specifying values (or not) isIPv4Available/isIPv6Available which indicates which stacks are available a complete consistent set of values for the IP addresses that JGroups needs This design does not meet requirement 3 if the user specifies one or more values. That is, he could specify IPv6 addresses when in fact the JVM has only an IPv4 stack available, or has a preference for an IPv4 stack. That could be changed by additionally checking if the consistent set of values specified by the user also is supported with a stack on the host (as is done in the case where no values are specified). Don't know how involved you want JGroups to be in checking IP address configuratioin. This could be achieved for little extra cost by checking stack availability before hand. With respect to probe.sh/Probe.java, I believe we need to also check what kind of stacks we have available in order to be able to multicast, without handling exceptions for stacks not being available. This would keep all the IP version stuff separate from the general code. For the case of TCPPING and making defaults for initial_hosts consistent, could this be done within TCPPING when it received the LOCAL_ADDR and check consistency between LOCAL_ADDR and its initial hosts parameters? If the address passed in by LOCAL_ADDR and the specified values for initial_hosts don't agree, then raise an exception and don't start the stack. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira