Subject: Re: discarded packets - msg#00044

Previous Message by Date: click to view message preview

Re: a fix for cross talk

Yes, I understand your argument. However, for some reason this behaves incorrectly. I can't get a multicast application to work properly (non-crosstalk) without specifying the host and the port in the multicast socket constructor. Again, this may be somewhat specific to the operating system or JDK combination I'm using. The JDK should handle this better. When I made the modification in the jgroups code, the crosstalk went away. On 5/16/07, Bela Ban <belaban@xxxxxxxxx> wrote: > I fail to see why this would fix things. If you look at the code of > UDP.createSockets(), I actually do set the interface later on *if* > bind_addr is set. Look at > mcast_sock.setInterface()/setNetworkInterface() further down the code. > (Note that I merged mcast_send_sock and mcast_recv_sock into mcast_sock). > Setting the interface has the same effect as using the > <SocketAddress,port> constructor > > > Greg Gimler wrote: > > Upon further investigation of the problem I experienced I found a > > solution. In the jgroups source I changed: > > > > src/org/jgroups/protocols/UDP.java > > > > to create the multicast socket in the following manner: > > > > mcast_recv_sock=new MulticastSocket(new InetSocketAddress(tmp_addr, > > mcast_port)); > > > > > > This solved my issue and my application no longer receives traffic > > that happens to be coming on the same port but with a different > > address. This may be specific to linux and kernel versions. I'm > > using Fedora Core 6, kernel 2.6.2 with jdk 1.5.0_10. > > -- > Bela Ban > Lead JGroups / JBoss Clustering team > JBoss - a division of Red Hat > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/

Next Message by Date: click to view message preview

Re: a fix for cross talk

I noticed that tmp_addr points to 228.1.1.1::7500, this is *not* a valid bind address. Can you create a JIRA and attach your patch to UDP.java ? jira.jboss.com, name=JGRP Greg Gimler wrote: > Yes, I understand your argument. However, for some reason this > behaves incorrectly. I can't get a multicast application to work > properly (non-crosstalk) without specifying the host and the port in > the multicast socket constructor. Again, this may be somewhat > specific to the operating system or JDK combination I'm using. The > JDK should handle this better. When I made the modification in the > jgroups code, the crosstalk went away. -- Bela Ban Lead JGroups / JBoss Clustering team JBoss - a division of Red Hat ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/

Previous Message by Thread: click to view message preview

Re: discarded packets

Thank you for pointing me to that. However, their solution is to make sure you use different addresses and ports for each socket. I don't think this is a very good solution and is a severe limitation. You should be able to have 2 different multicast addresses with the same port and not see the same traffic on both. On 5/16/07, Bela Ban <belaban@xxxxxxxxx> wrote: > The issue you're seeing is explained in > http://wiki.jboss.org/wiki/Wiki.jsp?page=TwoClustersSameNetwork and > http://wiki.jboss.org/wiki/Wiki.jsp?page=PromiscuousTraffic. The 2nd > link contains a solution as well. > > Greg Gimler wrote: > > Hello, > > > > 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 > > > > Somehow it is picking up the traffic being sent on 228.0.0.2:50000 but > > I'm unsure how this is occuring. Any ideas? My stack is listed below > > for reference? > > > > > > Thanks. > > > > -Greg > > > > > > ---Begin > > Stack------------------------------------------------------------------------------- > > > > "UDP(bind_addr="+bindAddress+";"+ > > "mcast_port="+mcastPort+";"+ > > "mcast_addr="+mcastAddr+";"+ > > "tos=8;"+ > > "ucast_recv_buf_size=20000000;"+ > > "ucast_send_buf_size=640000;"+ > > "mcast_recv_buf_size=25000000;"+ > > "mcast_send_buf_size=640000;"+ > > "loopback=false;"+ > > "discard_incompatible_packets=true;"+ > > "max_bundle_size=64000;"+ > > "max_bundle_timeout=30;"+ > > "use_incoming_packet_handler=true;"+ > > "use_outgoing_packet_handler=false;"+ > > "ip_ttl="+ttl+";"+ > > "down_thread=false;up_thread=false;"+ > > "enable_bundling=false):"+ > > > > "PING(timeout=2000;"+ > > > > "down_thread=false;up_thread=false;num_initial_members=3):"+ > > > > "MERGE2(max_interval=100000;"+ > > "down_thread=false;up_thread=false;min_interval=20000):"+ > > > > "FD_SOCK(down_thread=false;up_thread=false):" + > > > > > > "FD(timeout=10000;max_tries=5;down_thread=false;up_thread=false;shun=true):"+ > > > > "VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):"+ > > > > "pbcast.NAKACK(max_xmit_size=60000;use_mcast_xmit=false;gc_lag=0;" + > > "retransmit_timeout=300,600,1200,2400,4800;down_thread=false > > up_thread=false;" + > > "discard_delivered_msgs=true):"+ > > > > > > "UNICAST(timeout=300,600,1200,2400,3600;down_thread=false;up_thread=false):"+ > > > > "pbcast.STABLE(stability_delay=100;desired_avg_gossip=5000;"+ > > "down_thread=false;up_thread=false;max_bytes=400000):"+ > > > > > > "pbcast.GMS(print_local_addr=true;join_timeout=3000;use_flush=true;flush_timeout=3000;"+ > > "down_thread=false;up_thread=false;"+ > > "join_retry_timeout=2000;shun=false;"+ > > "view_bundling=true;"+ > > "view_ack_collection_timeout=5000):"+ > > > > "FC(max_credits=2000000;down_thread=false;up_thread=false;"+ > > "max_block_time=4611686018427387904;min_threshold=0.10):" + > > > > "FRAG2(frag_size=60000;down_thread=false;up_thread=false):"+ > > > > > > "pbcast.STREAMING_STATE_TRANSFER(down_thread=false;up_thread=false;use_flush=true;" > > + > > "flush_timeout=3000;use_reading_thread=true):"+ > > > > > > "pbcast.FLUSH(down_thread=false;up_thread=false;timeout=20000;auto_flush_conf=false)" > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > javagroups-users mailing list > > javagroups-users@xxxxxxxxxxxxxxxxxxxxx > > https://lists.sourceforge.net/lists/listinfo/javagroups-users > > > > > > -- > Bela Ban > Lead JGroups / JBoss Clustering team > JBoss - a division of Red Hat > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/

Next Message by Thread: click to view message preview

Re: discarded packets

Bela Ban wrote: > > Greg Gimler wrote: >> Thank you for pointing me to that. >> >> However, their solution is to make sure you use different addresses >> and ports for each socket. I don't think this is a very good solution >> and is a severe limitation. You should be able to have 2 different >> multicast addresses with the same port and not see the same traffic on >> both. > > Understood, and agreed. This is a bug in the OS, I think someone wrote > the same code in C and it didn't work either. Note that this works on > Windows (XP) and Linux though. > Yes, Aleksander Kostadinov wrote a C test that shows it; you can see it on https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231899. Just to clarify; this problem does exist on Linux (not just Red Hat; we saw it on SuSE as well). We don't see it on Windows XP and Solaris. If you want to test your OS you can have a look at the C test attached to the above bugzilla, or use the Java-based test attached to http://wiki.jboss.org/wiki/Wiki.jsp?page=PromiscuousTraffic. -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry@xxxxxxxxxx ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/