[jboss-jira] [JBoss JIRA] Commented: (JGRP-515) UDP.java requires the multicast address in the multicastsocket constructor to fix crosstalk on certain operating systems

Brian, We opened this issue in the RHEL Bugzilla: http://wiki.jboss.org/wiki/Wiki.jsp?page=PromiscuousTraffic <http://wiki.jboss.org/wiki/Wiki.jsp?page=PromiscuousTraffic>https://bu... As you can see, we even attached a program to reproduce the issue. They have closed the issue as NOTABUG.

Aleksandar suggested that we write the program as the suggested and perhaps reopen the bug: The only thing left to check is if binding to the proper socket will result in the desired behavior. I mean 2 processes can bind to the same address(group)/port as well not receive mcast messages to other groups. Should we pursue the issue? I think we have a fair chance of getting it fixed if we can demonstrate that they violate the RFC. Thanks, Ryan ------------------------------------------------------------------------ Subject: [Fwd: [Bug 231899] multicast incorrect handling] From: Aleksandar Kostadinov Date: Tue, 22 May 2007 16:25:13 +0300 To: Ryan Campbell To: Ryan Campbell seems reasonable... http://tldp.org/HOWTO/Multicast-HOWTO-2.html#ss2.4 The only thing left to check is if binding to the proper socket will result in the desired behavior. I mean 2 processes can bind to the same address(group)/port as well not receive mcast messages to other groups. ------------------------------------------------------------------------

------- Additional Comments From xxxx 2007-05-22 08:55 EST ------- According to the email as I read it, and from what I understand of the RFC, This is working exactly as designed. the mcreceive program binds to INADDR_ANY before adding multicast membership. That means the socket in each mcreceive process should receive all multicast traffic from all groups that any process is added to, which is exactly what you are seeing. If you want only the first process to receive multicast frames, then you should write a separate program to run in step 2 that binds to 225.12.12.14:1444, rather than INADDR_ANY. the Jboss kbase entry should be fixed to reflect that.

UDP.java requires the multicast address in the multicastsocket constructor to fix crosstalk on certain operating systems ------------------------------------------------------------------------------------------------------------------------ Key: JGRP-515 URL: http://jira.jboss.com/jira/browse/JGRP-515 Project: JGroups Issue Type: Patch Environment: Tested on Fedora Core 6, JDK 1.5.0_10 Reporter: ggimler Assigned To: Bela Ban Fix For: 2.5 Attachments: mcreceive.c, mcsend.c, UDP.java I'm submitting a patch for a crosstalk issue described below. I'm trying to debug a problem I'm seeing when running JGroups on the same network/machine as another application that is sending/receiving data via regular multicast (not through JGroups). I'm using version 2.4.1-SP3. My scenario is as follows... JGroups send on 228.0.0.1:50000 JGroups receive on 228.0.0.1:50000 This works fine. When I start up another application that does Sends regular multicast on 228.0.0.2:50000 Receives regular multicast on 228.0.0.2:50000 Then the JVM with the JGroups sender/receiver complains with: May 15, 2007 4:47:59 PM org.jgroups.protocols.TP handleIncomingPacket WARNING: packet from 192.168.101.133:36594 has different version (26725) from ours (2.4.1). Packet is discarded The patch is in UDP.java: