JDK-4686717 : Wrong description of parameter semantics for JDK 1.4 setLoopbackMode()
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-05-16
  • Updated: 2003-03-28
  • Resolved: 2002-09-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
Relates :  
Description

Name: nt126004			Date: 05/16/2002


FULL PRODUCT VERSION :
Windows:
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

Solaris:
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

Linux:
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)


FULL OPERATING SYSTEM VERSION :
Windows 2000 SP2

ADDITIONAL OPERATING SYSTEMS :
SunOS 5.8 Generic_108528-11 sun4u sparc SUNW,Ultra-60
SuSE Linux 8.0, Kernel 2.4.18



A DESCRIPTION OF THE PROBLEM :
This is either a documentation problem or an implementation bug.

JDK 1.4 doc states that a parameter value of 'true' is
required to switch loopback mode off for a MulticastSocket.

The attached client/server programs show that calling
setLoopbackMode(false) switches off loopback of packets
coming from the same host.

It seems that setLoopbackMode/getLoopbackMode - contrary to
the doc. - act as setter/getter methods that take/return
the value for the loopback mode to set/get

See:
http://java.sun.com/j2se/1.4/docs/api/java/net/MulticastSock
et.html#setLoopbackMode(boolean)
http://java.sun.com/j2se/1.4/docs/api/java/net/MulticastSock
et.html#getLoopbackMode()


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. compile attached files (client and server)
2. run one or more instances of MulticastServer
3. run Multicastclient on same host
4. change parameter to setLoopbackMode to demonstrate effect

EXPECTED VERSUS ACTUAL BEHAVIOR :
Calling setLoopbackMode(true) should disable loopback mode,
i.e. servers should not receive packets from client running
on same host.
Actual result is: calling setLoopbackMode(false) achives
the desired effect.

SideNode:
On Windows disabling loopback mode on the server side
achives the effect (no reception of packets coming from
same host). On Solaris, loopback mode has to be disabled on
the client side.

On Linux:
Works like on Solaris - but only if IPV6 disabled (Kernel
2.4.18)
With IPV6 enabled, the JVM calls
setsockopt(5, SOL_IPV6, 19, [0], 4)     = 0




This bug can be reproduced always.

---------- BEGIN SOURCE ----------
//
// MulticastClient.java
//

import java.net.*;

public class MulticastClient
{
    public static void main(String args[])
    {
	System.out.println("MulticastClient");
	try
	{
	    InetAddress group = InetAddress.getByName("228.5.6.7");
	    MulticastSocket mcs = new MulticastSocket(12345);
	    //
	    // Switch off loopback mode
	    //
	    mcs.setLoopbackMode(false);  // JDK 1.4 doc says 'true' for disable
	    mcs.joinGroup(group);

	    boolean loopbackMode = mcs.getLoopbackMode();
	    System.out.println("LoopbackMode: " + loopbackMode);
	    
	    String msg = "Hello";
	    DatagramPacket hi =
		new DatagramPacket(msg.getBytes(), msg.length(), group, 12345);
	    
	    while (true)
	    {
		System.out.println("Sending: " + msg);
		mcs.send(hi);
		try
		{
		    Thread.sleep(1000);
		}
		catch(InterruptedException ex)
		{
		}
	    }

	}
        catch(java.io.IOException ex)
        {
	    System.out.println(ex);
        }
    }
}

//
// MulticastServer.java
//

import java.net.*;

public class MulticastServer
{
    public static void main(String args[])
    {
	System.out.println("MulticastServer");
	try
	{
	    InetAddress group = InetAddress.getByName("228.5.6.7");
	    MulticastSocket mcs = new MulticastSocket(12345);
	    //
	    // Switch off loopback mode
	    //
	    mcs.setLoopbackMode(false);  // JDK 1.4 doc says 'true' to disable
	    mcs.joinGroup(group);
	    
	    boolean loopbackMode = mcs.getLoopbackMode();
	    System.out.println("LoopbackMode: " + loopbackMode);
	    
	    while(true)
	    {
		byte[] buf = new byte[50];
		DatagramPacket recv = new DatagramPacket(buf, buf.length);
		mcs.receive(recv);
		String msg = new String(buf);
		System.out.println("Received: " + msg);
	    }
	}
        catch(java.io.IOException ex)
        {
	    System.out.println(ex);
        }
    }
}

---------- END SOURCE ----------

CUSTOMER WORKAROUND :
treat parameter to setLoopbackmode() as the desired
loopback mode to set (false = loopbackmode off, true =
loopbackmode on).

Correct documentation.
(Review ID: 146673) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b03 VERIFIED IN: mantis-beta
14-06-2004

EVALUATION There are 3 issues here :- 1. Implementation isn't following the specification - specifically setLoopbackMode(true) caues us to enable loopback rather than disable it - this should be fixed for mantis. 2. The IP_MULTICAST_LOOP option has different semantics on Windows vs. Solaris/Linux. Specifically it applies to the receive path on Windows whereas it applies to the send path on Solaris/Linux. Addressing this is non-trival so this would be post-poned until tiger - see 4701650. 3. Multicasting through the loopback on Linux is broken if IPv6 is enabled - this is a known Linux kernel/IPv6 bug. A similiar issue arises on Solaris 8 (fixed in Solaris 9) - see 4491720. ###@###.### 2002-05-20 Please note that as items 2 & 3 are covered by other bugs this bug is now only tracking item 1 with a view to fixing it in mantis. ###@###.### 2002-06-13
20-05-2002