#12 Jmmdns Interface

open
5
2011-12-27
2011-12-27
No

After some testing around the multi-homed jmmdns interface, some obversations that might contribute to improving it.

I have a network which is constantly up/down or going out of range (mobile robots), so that is an important part of it. With the current code, I had to implement my own NetworkTopologyListener to handle this.

This gets messy when wanting to add listeners. With the current jmmdns interface, its a one-shot call. It has no memory, so when new interfaces go up, or old ones go down and then up again, it doesn't remove/re-add them.

I had to extend the jmmdns interface to do this, save them when I called my own addListener api, and then individually add them from this saved list to the jmdns interfaces whenever the network topology callback fired. Which ultimately means I end up ignoring jmmdns' addListeners and doing all the grunt work underneath. The very same thing occurs with adding services.

I expect this should be expected behaviour. All of this work would actually be nicely buried under the hood and would make the jmmdns api (specifically addListener, addService) actually usable. A network topology callback might still be useful, but jmmdns could have its own callback which does all the above mentioned work and then calls the user's callback.

Apart from that, jmmdns is a nice start :)

Discussion

  • Pierre Frisch

    Pierre Frisch - 2011-12-27

    Hi Daniel,

    I don't really understand what you need. Could you share un example or some sample code of what you think should happen. I don't understand what "it has no memory" means. You are supposed to get a call for the appearance and one for the disappearance of each interface. isn't this what you are getting? Why would you want JmmDNS to memorize past info?

    If you check the list there are a number of bugs in JmmDNS that I am working on. In particular the listener are not always added correctly when the interface is added. This is a known bug and I would appreciate ideas as it is quite complex to fix.

    Cheers

    Pierre

     
  • Pierre Frisch

    Pierre Frisch - 2011-12-27
    • assigned_to: nobody --> spearway
     
  • Daniel Stonier

    Daniel Stonier - 2011-12-31

    Our constraining assumption for robots is that the network is likely to be up/down quite alot. If my program does the following:

    1) Create a JmmDNS instance
    2) Add service listener via JmmDNS::addServiceListner()

    Then, if we start without the network interface up, the default JmmDNS will do nothing inside the JmmDNS::addServiceListener() call as there is no _knownMDNS values. The request is also not stored anywhere, so if the network interface comes up later, then no service listener will be added to the new JmDNS instance that will get created in JmmDNS::inetAddressAdded(). This is what I mean by the fact it has no memory.

    A similar difficult situation arises if the interface goes down (it wipes all listeners) and comes up again (doesn't re-add them because it hasn't saved the request anywhere).

    To get around this, I extended JmmDNS with my own addServiceListener (which saves a request and adds it to any existing JmDNS instances) and created my own NetworkTopologyListener where I add saved requests to the newly created JmDNS instance.

    I think this is probably very standard behaviour - would it be problematic in having it as the default NetworkTopologyLIstener behaviour?

     
  • Pierre Frisch

    Pierre Frisch - 2011-12-31

    Ok I understand your problem. I have been working on a solution for some time and you can see the implementation in HEAD. This is however untested code. I have been trying to create unit test for it but this is long, arduous code and I have a lot less time for JmDNS than I would like. I would enjoy sharing the load.

     
  • Daniel Stonier

    Daniel Stonier - 2012-01-01

    I think I probably have a couple of good test programs for it now, so I can help there. I am still learning java though, so there are areas where I'm not so sure I'm hacking the right way and wouldn't trust myself to let loose inside jmdns just yet. I can point out where I see issues though, and if you can provide some hints on where it would be best to hit the problem, that might be a good way forward.

    A brief update on where I am at. Publishing and discovery via polling (i.e. regularly calling jmmdns.list() seems fine. That leaves problem areas at the moment as:

    1) Callback discovery (serviceAdded, serviceResolved, serviceRemoved)
    2) Network interface up and down
    3) Program stop/restart (especially on android - issues with jmmdns.close() and jmmdns.getInstance())
    4) Multiple network interfaces - some awkward issues here I need to understand better
    5) Some odd timing issues (showing up in android) that I haven't tracked down yet

    I've got two test programs, one is pure java and I can test the multiple network interfaces with that one. The other is android and is a good test case for callback discovery and networks up and down.

    Would you like to do a skype session sometime? It might be a good way to work out the most efficient way forward to improve jmdns.

     
  • Nobody/Anonymous

    Igj7R6 <a href="http://ofxwynufitiv.com/">ofxwynufitiv</a>, [url=http://asvxqvxhexur.com/]asvxqvxhexur[/url], [link=http://pogtjulbjtix.com/]pogtjulbjtix[/link], http://eyjxryhbsukc.com/