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

[Bela Ban (JIRA)]

    [ http://jira.jboss.com/jira/browse/JGRP-515?page=comments#action_12364654 ] 
            
Bela Ban commented on JGRP-515:
-------------------------------

Forwarding to Bela for his comment as what Neil Horman said _may_ relate to a discussion he's been having with a user on the JGroups list.

Unless Bela comes back and says Neil's comment has changed his opinion on how this stuff should work, I think we should pursue the issue.

Ryan Campbell wrote:
> 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://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231899
>
> 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.
>


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat




> 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:

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