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
groups.


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