[
http://jira.jboss.com/jira/browse/JGRP-515?page=comments#action_12362477 ]
ggimler commented on JGRP-515:
------------------------------
I've also seen this issue on Redhat Enterprise Linux 4 (not just Fedora). I don't
think specifying the class D address you want to listen to in the MulticastSocket
constructor would pick the wrong NIC though I haven't tested this because I've
only run this on a single homed machine. What about another option in the UDP protocol
stack to specify this?
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: 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:
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira