[ http://jira.jboss.com/jira/browse/JGRP-515?page=comments#action_12362437 ] Bela Ban commented on JGRP-515: ------------------------------- mcast_sock only bind to a NIC for *sending* of messages, but not for reception: it actually receives multicast packets on *all* interfaces (wildcard address 0.0.0.0). Code is UDP.createSockets(): mcast_sock=new MulticastSocket(mcast_port); We should change this to: SocketAddress saddr=new InetSocketAddress(bind_addr, mcast_port); mcast_sock=new MulticastSocket(saddr); -- 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

[ http://jira.jboss.com/jira/browse/JGRP-515?page=comments#action_12362461 ] Bela Ban commented on JGRP-515: ------------------------------- This attached patch (for 2.4) doesn't work, as it tries to bind to the multicast (class D) address, which is *not* a valid interface: tmp_addr=InetAddress.getByName(mcast_addr_name); mcast_recv_sock=new MulticastSocket(new InetSocketAddress(tmp_addr, mcast_port)); So tmp_addr is (for example) 228.10.10.15, which will fail on creation of the MulticastSocket as this is not a valid interface ! -- 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

[ http://jira.jboss.com/jira/browse/JGRP-515?page=all ] Bela Ban resolved JGRP-515. --------------------------- Resolution: Won't Fix As explained in comment -- 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

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

[ http://jira.jboss.com/jira/browse/JGRP-515?page=comments#action_12362508 ] ggimler commented on JGRP-515: ------------------------------ If I run it then it works for me on Fedora Core 6 with JDK 1.5.0_10 and it works on Redhat Enterprise AS release 4 Update 3. I am creating the socket with 225.0.6.12. I haven't tried Windows yet. ggimler@dacia:~/workspace/perseus/bin$ ./mcastrcv reliable 225.0.6.12 14001 1000 192.168.101.* Receiving data in reliable mode with JGroups. received 0 messages. Average latency = 0 ms May 18, 2007 9:25:35 AM org.jgroups.JChannel init INFO: JGroups version: 2.4.1 SP-3 May 18, 2007 9:25:35 AM org.jgroups.protocols.FRAG2 setProperties INFO: frag_size=60000, overhead=200, new frag_size=59800 May 18, 2007 9:25:35 AM org.jgroups.protocols.FRAG2 up INFO: received CONFIG event: {bind_addr=/192.168.101.133} May 18, 2007 9:25:35 AM org.jgroups.protocols.UDP createSockets INFO: sockets will use interface 192.168.101.133 May 18, 2007 9:25:35 AM org.jgroups.protocols.UDP createSockets INFO: socket information: local_addr=192.168.101.133:32789, mcast_addr=225.0.6.12:14001, bind_addr=/192.168.101.133, ttl=32 sock: bound to 192.168.101.133:32789, receive buffer size=131071, send buffer size=131071 mcast_recv_sock: bound to 192.168.101.133:14001, send buffer size=131071, receive buffer size=131071 mcast_send_sock: bound to 192.168.101.133:32791, send buffer size=131071, receive buffer size=131071 ------------------------------------------------------- GMS: address is 192.168.101.133:32789 ------------------------------------------------------- received 0 messages. Average latency = 0 ms received 0 messages. Average latency = 0 ms received 0 messages. Average latency = 0 ms received 0 messages. Average latency = 0 ms received 0 messages. Average latency = 0 ms received 0 messages. Average latency = 0 ms May 18, 2007 9:25:41 AM org.jgroups.protocols.pbcast.CoordGmsImpl handleMembershipChange INFO: Successful GMS flush by coordinator at 192.168.101.133:32789 received 3 messages. Average latency = 106 ms received 13 messages. Average latency = 0 ms received 22 messages. Average latency = 0 ms received 32 messages. Average latency = 0 ms received 34 messages. Average latency = 0 ms ggimler@dacia:~/workspace/perseus/bin$ /sbin/route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.101.0 * 255.255.255.0 U 0 0 0 eth0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth0 default 192.168.101.1 0.0.0.0 UG 0 0 0 eth0 -- 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

[ 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 Stansberry Lead, AS Clustering JBoss, a division of Red Hat -- 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

[ http://jira.jboss.com/jira/browse/JGRP-515?page=all ] Bela Ban updated JGRP-515: -------------------------- Attachment: mcsend.c -- 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

[ http://jira.jboss.com/jira/browse/JGRP-515?page=comments#action_12364865 ] Bela Ban commented on JGRP-515: ------------------------------- If I make the suggested change in mcreceive.c: /* construct a multicast address structure */ memset(&mc_addr, 0, sizeof(mc_addr)); mc_addr.sin_family = AF_INET; // mc_addr.sin_addr.s_addr = htonl(INADDR_ANY); mc_addr.sin_addr.s_addr = inet_addr(mc_addr_str); // <==== changed ! mc_addr.sin_port = htons(mc_port); , where I bind to the multicast address and port, then this works on Linux (Fedora 7), but fails on Windows: $ ./mcreceive.exe 228.8.8.8 7500 bind() failed: Cannot assign requested address (my routing table is below) I thought that bind() had to accept the address associated with a local network interface, so that a class D address is invalid. Network Destination Netmask Gateway Interface Metric 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.5.0 255.255.255.0 192.168.5.2 192.168.5.2 10 192.168.5.2 255.255.255.255 127.0.0.1 127.0.0.1 10 192.168.5.255 255.255.255.255 192.168.5.2 192.168.5.2 10 224.0.0.0 240.0.0.0 192.168.5.2 192.168.5.2 10 255.255.255.255 255.255.255.255 192.168.5.2 192.168.5.2 1 -- 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

[ http://jira.jboss.com/jira/browse/JGRP-515?page=all ] Bela Ban closed JGRP-515. ------------------------- Resolution: Rejected Suggested solution is not portable across multiple operating systems. IMO, Linux violates the mcast spec if it allows binding the MulticastSocket to a class D address. Please reopen this if you find a solution that is platform independent -- 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