United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4686717 : Wrong description of parameter semantics for JDK 1.4 setLoopbackMode()

Details
Type:
Bug
Submit Date:
2002-05-16
Status:
Closed
Updated Date:
2003-03-28
Project Name:
JDK
Resolved Date:
2002-09-26
Component:
core-libs
OS:
windows_2000
Sub-Component:
java.net
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.4.0
Fixed Versions:
1.4.2 (mantis)

Related Reports
Relates:
Relates:

Sub Tasks

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


                                     
2004-06-14
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
                                     
2002-05-20



Hardware and Software, Engineered to Work Together