JDK-4701650 : MulticastSocket spec issues
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic,windows_nt
  • CPU: generic,x86
  • Submitted: 2002-06-13
  • Updated: 2018-02-06
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
This bug is submitted to collect the various MulticastSocket specification
and implementation issues that should be addressed in tiger :-

1. MulticastSocket(SocketAddress) ctor can be used to bind to a specific
address. This is problematic because on many operating systems you can
only receive multicast packets when bound to the wildcard address.

Two alternative to examine: (a) amend specification to indicate that
binding to a specific address leads to undefined behaviour, or (b) change
the implementation so that it always binds to the wildcard address but
subsequently filters any packets not destined for the specific address.

2.  MulticastSocket(SocketAddress) ctor can be used to bind to a 
multicast address on some operating system. As per item 1 there are two
alternatives: (a) amend specification as per 1, or (b) validate that the
address is a local address (which could break some existing code if 
anyone is relying on this).

3. joinGroup/leaveGroup(InetAddress) need improved specifications.

Specifically the "side effect of setInterface/setNetworkInterface"
isn't clear and should be described more clearly. Also joinGroup 
joins groups cummulatively and this should be specified.

Also, in 1.4 we can create unbound socket and joinGroup/leaveGroup
don't specify what should happen if someone attempts to join a 
group even though the socket isn't bound yet.

4. joinGroup/leaveGroup(InetAddress,NetworkInterface) specify the
NetworkInterface argument incorrectly - the specification should state
that it's the interface to join the group. 

Additionally, when NetworkInterface is null isn't completed specified
- eg:  if outgoing interface hasn't been set via setNetworkInterface
then joinGroup(mg, null) behaves as joinGroup(mg).

5. setLoopbackMode()'s implementation isn't following the specification
and setLoopbackMode(true) is enabling loopback rather than disabling it.
This should be fixed for mantis - see 4686717.

Additionally, the The IP_MULTICAST_LOOP socket option has different semantics 
on Windows vs. Solaris/Linux - it applies to the receive path on Windows 
whereas it applies to the send path on Solaris/Linux. 

Also, the IPV6_MULTICAST_LOOP setting on Linux doesn't appear to work
if the an IPv6 socket sends an IPv4 multicast - this is a Linux IPv6
bug that should be chased up with USAGI.

6. MulticastSocket needs new API support so that applications can enumerate
the multicast groups that have been joined. There are a number of options
to investigate as it might be desirable to return an enumeration that
includes both the groups and the network interfaces that joined those

7. As per Socket/ServerSocketDatagramSocket the behaviour of socket options
on unbound or closed sockets is not defined. For example setting the
multicast TTL or the loopback mode on an unbound socket is not defined.

8. The overall specification for MulticastSocket could do with a 
face-lift as it dates back to JDK1.1. For example it doesn't mention
network interfaces, no mention of IPv6 multicast addresses, the comment
on applets not being allowed to use mutlicast sockets dates back to
before the Java 2 security model.

Additionally it needs to put in something to explain that an 
application may receive multiple copies of a multicast packet (in
a multi-homed environment for example).

###@###.### 2002-06-13

Todo: perform an assessment of the issues against 9 with an appropriate set of tests .... of note is that Multi-homed environments with IPv6 configurations cause some difficulties ....

EVALUATION -- (10/30/05) We created this bug after 1.4 shipped to track specification clean-ups that are needed to the java.net.MulticastSocket specification. Items 1 & 2 will probably result in a warning in the specification that binding to a specific or multicast address will lead to wildly platform specific behaviour. Items 3, 4, 7, and 8 are also documentation items to clarify and clean-up various aspects of the specifictaion. Item 5 was fixed in 1.4.x so the only implementation item remaining is item 6 (a low priority requirement for a method to enumerate the multicast groups that have been joined). So while this bug is mostly specification clean-up it has found its way into the JDC top-25 with 150+ votes. It would be good to hear from developers that are voting for this bug. Are you concerned about the specification clarifications or are you running into other multicasting issues? As an aside, we have fixed a number of multicasting issues on Linux in recent releases. Linux distributions in recent years have shipped with IPv6 enabled and as a result J2SE based networking applications will use IPv6 sockets. We've been burned by several changes in the USAGI implementation and we have updated our implementation as USAGI has envolved. It would be good to know if those voting for this issue are voting about Linux specific problems or perhaps something else.

EVALUATION Important to have MulticastSocket right for tiger.