SourceForge has been redesigned. Learn more.
Close

#133 Network flood with many hosts.

open
networking (37)
5
2013-01-24
2012-07-09
Anonymous
No

Hi

Using 3.4.1 there appears to be a network flood issue with JmDNS. Attached is a quick tcpdump which illuatrates what I\'m talking about (this is using: tcpdump -n -i en0 udp port 5353 > pcap.txt ). The issue can saturate a 100MBit link.

The network topology is as follows:
Our app uses JMDns to \'know\' about other instances of itself running on our network. This means that there are about 40 registered service listeners on different computers *and* multiple instances on a terminal services machine (which has a single IP)

I\'ve put a very crude (horrible!) hack in to mitigate the issue (basically doesn\'t allow JmDNS to .send(DNSOutgoing) duplicate packets for at least 3 seconds), and this appears to fix the issue without degrading functionality

Discussion

  • Nobody/Anonymous

     
  • Pierre Frisch

    Pierre Frisch - 2012-07-09

    Interesting.

    Could you try to reproduce with HEAD? I am hopelessly late in releasing a new version and lots have been fixed in HEAD.

    Thanks

    Pierre

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous

    Anonymous - 2012-07-10

    Hi!

    Unfortunately I'm not able to reproduce anymore (since the hack I've put in has been rolled out in our product, everything has started to behave again).

    I *think* that this may be related to the fact we were running instances of our app on Terminal Services, which only has 1 physical IP for the box itself
    There are several instances of our app (each logged in user to Terminal Services runs our app) on the terminal server which has registered 1 service listener.

    Our terminal services box was the last machine to be updated with the fixes, and was quite happily still flooding the network until we did this - I think there may be an issue with multiple instances running on the same IP with the same service listener, and those instances conflicting with each other.

    In the pcap.txt, the IP for the TS box is 10.0.8.33 in case this helps

    The diff against 3.4.1 for the hack I stuck in is:

    $ svn diff -r HEAD
    Index: src/main/java/javax/jmdns/impl/DNSEntry.java
    ===================================================================
    --- src/main/java/javax/jmdns/impl/DNSEntry.java (revision 351)
    +++ src/main/java/javax/jmdns/impl/DNSEntry.java (working copy)
    @@ -276,7 +276,7 @@
    @Override
    public String toString() {
    StringBuilder aLog = new StringBuilder(200);
    - aLog.append("[" + this.getClass().getSimpleName() + "@" + System.identityHashCode(this));
    + aLog.append("[" + this.getClass().getSimpleName()); // Don't include the object hashcode so we can use this in our de-dupe method + "@" + System.identityHashCode(this));
    aLog.append(" type: " + this.getRecordType());
    aLog.append(", class: " + this.getRecordClass());
    aLog.append((_unique ? "-unique," : ","));
    Index: src/main/java/javax/jmdns/impl/JmDNSImpl.java
    ===================================================================
    --- src/main/java/javax/jmdns/impl/JmDNSImpl.java (revision 351)
    +++ src/main/java/javax/jmdns/impl/JmDNSImpl.java (working copy)
    @@ -61,6 +61,10 @@
    }

    /**
    + * Part of a hack to prevent the sending of duplicate packets for a set period of time - see .send(DNSOutgoing)
    + */
    + private HashMap<String, Long> sentHash = new HashMap();
    + /**
    * This is the multicast group, we are listening to for multicast DNS messages.
    */
    private volatile InetAddress _group;
    @@ -1532,8 +1536,27 @@
    }
    }
    final MulticastSocket ms = _socket;
    +
    if (ms != null && !ms.isClosed()) {
    - ms.send(packet);
    +
    + // very crude code to prevent the sending of duplicate packets
    + // DNSEntry has been modified to remove the object id hash() so we can use toString()
    + boolean duplicate = false;
    + Long lastOut = sentHash.get(out.toString());
    + if (lastOut != null) {
    + if (lastOut.longValue() > System.currentTimeMillis()) {
    + duplicate = true;
    + }
    + }
    + sentHash.put(out.toString(), System.currentTimeMillis()+3000);
    + if (sentHash.size() > 500) {
    + sentHash.clear();
    + }
    +
    + // Send the packet if it's not a duplicate within X seconds
    + if (!duplicate){
    + ms.send(packet);
    + }
    }
    }
    }

     
    Last edit: Anonymous 2014-04-04
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous

    Anonymous - 2012-07-10

    Diff included on: http://ian-hawkins.com/misc/jmdnsdiff.txt for better readability (didn't realise the comment system stripped leading spaces)

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous

    Anonymous - 2012-07-10

    Issue appears to be still present in HEAD

     
    Last edit: Anonymous 2014-05-01
  • Pierre Frisch

    Pierre Frisch - 2012-07-10

    I understand what you are trying to do with the hack but this treating the symptom not the cause. I need to understand why we are repeating the same packet.

    Is there some reasonable setup or test I could reproduce? Does this happen immediately or in response to some event? Could you capture a binary dump of the packet being repeated that may sent me in the right direction.

    Cheers

    Pierre

     
  • Nobody/Anonymous

    I absolutely love your blog and find a lot of your post's to be just what I'm looking for. Do you offer guest writers to write content available for you? I wouldn't mind creating a post or elaborating on a few of the subjects you write concerning here. Again, awesome weblog!
    Beats by dre black http://www.beatsbydreoutletsus.net/