DNS-SD: Experience with “mdnsjava”? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 4 years ago.

Improve this question

I'm right now implementing the DNS-DS library "mdnsjava" into my Android-project as it's mentioned at several positions, for example here at SO:

Are there any other Java libraries for bonjour/zeroconf apart from JMDNS?.

While implementing, I wonder if this implementation is really using any cache and/or how stable it might perform.

Right now I'm using jmDNS for the last 2 years but this library wasn't able to keep the cache while pausing the discovery (app in background).

Additionally, jmDNS was slow & unstable with discovering the devices.

So, has anyone any experience with mdnsjava?

Answer 1

Meanwhile I can say, that mdnsjava is working very very good and stable in most situations. Much better & faster compared to jMDNS.

Here's some code to restart the full discovery and to start/stop the discovery, maybe it helps someone:

MulticastDNSService mDNSService = null;
Browse browse = null;
Object serviceDiscoveryInstance = null;

public void stop() {
    try {
        if (serviceDiscoveryInstance != null && mDNSService != null) {
            mDNSService.stopServiceDiscovery(serviceDiscoveryInstance);
            mDNSService.close();
        }

        serviceDiscoveryInstance = null;
        //mDNSService = null;
        if (browse != null) {
            browse.close();
            // this is required, otherwise the listeners won't get called in next run
            browse = null;
        }

        Querier querier = MulticastDNSLookupBase.getDefaultQuerier();
        if (querier != null) {
            querier.close();
        }
        MulticastDNSLookupBase.setDefaultQuerier(null);
    } catch (Exception e) {
        Log(..)
    }
}

public void start() {
    try {
        Querier querier = MulticastDNSLookupBase.getDefaultQuerier();
        if (querier != null) {
            if (mDNSService == null) {
                mDNSService = new MulticastDNSService();
            }

            if (browse == null) {
                browse = new Browse(SERVICE_TYPE);
            }

            if (serviceDiscoveryInstance == null) {
                serviceDiscoveryInstance = mDNSService.startServiceDiscovery(browse, this);
            }

            // add existing entries
            Lookup resolve = new Lookup(SERVICE_TYPE);
            resolve.setQuerier(mDNSService.getQuerier());
            ServiceInstance[] services = resolve.lookupServices();
            for (ServiceInstance service : services) {
                addDevice(service);
            }
            resolve.close();
        } else {
            Log.e("Cannot start mDNS-discovery because querier is not set up!");
            resetDiscovery();
        }
    } catch (Exception e) {
        Log.e("Error while discovering network.", e);
        resetDiscovery();
    }
}

public void clearCaches() {
    if (MulticastDNSCache.DEFAULT_MDNS_CACHE != null) {
        MulticastDNSCache.DEFAULT_MDNS_CACHE.clearCache();
    }
    mDNSService = null;
    browse = null;
}

private void resetDiscovery(){
    stop();
    mDNSService = null;
    browse = null;
}

You can start/stop the discovery with the mentioned methods, and reset the whole discovery via

stop();
clearCaches();
start();

Answer 2

I switched from JmDNS to mdnsjava because JmDNS simply didn't seem to work properly. Sometimes it would not detect anything.

I have very good experience with mdnsjava and have contributed slightly to it, by adding a pom.xml and pointed at a few simple bug-fixes. The only thing about mdnsjava is that it doesn't seem to be able to completely restart itself from scratch for some reason (reset exactly all state of the running program), but as long as it's up it works flawlessly for me. I didn't notice any other problems with my Android background-services using it. I pointed about the reset problem to the author, and he said he had experienced the same issue, and that if he had time, he might look at it some day.