In addition to unifying multiple mDNS implementations under a single API, I think my API reduces the amount of work needed by the developer for registering and listening for services to a minimum.

Building the code
First off, all you should need to compile and run my package is Maven. Once you have Maven installed, cd into the jmdns directory, and run:

mvn test

This will compile JmDNS, my add-on API, and run a few unit tests. The API in question is tested by org.jmdns.api.DiscoveryFactoryTest. I would expect the JmDNS portion of the test testJmDNS() to pass under almost any circumstance, but the testmDNSResponder() will only pass if you are running on Linux and have mDNSResponder (or possibly the avahi compatibility layer) installed successfully.

Example usage – Initialization

Before registering or listening for services, you need to initialize the discovery subsystem:

DiscoveryFactory.initRegistry( DiscoveryFactory.DISCOVERY_REGISTRY_DEFAULT);

The above will use the default mDNS implementation (JmDNS). Alternatively you can use the following to use JmDNS explicitly:

DiscoveryFactory.initRegistry( DiscoveryFactory.DISCOVERY_REGISTRY_JMDNS);

Or mDNSResponder instead:

DiscoveryFactory.initRegistry( DiscoveryFactory.DISCOVERY_REGISTRY_MDNSRESPONDER);

Consider this an initialization a singleton, you should do this once and only once per JVM instance.

Example usage – Registering a Service

Assuming the system is initialized, the following code will register a service:

HashMap<string,> props = new HashMap<string,>(); props.put("type", "website");</string,></string,>

IDiscoveryRegistry registry = DiscoveryFactory.getRegistry();

IServiceInfo myService = registry.registerService("_http._tcp", "mySite", null, 80, props);

Note the ‘null’ in the registerService() call is to use the default domain (.local). You can pass a domain name here to register in another domain.

To unregister your service, just do:

registry.unregisterService(myService);

Example usage – Listening for a Service

Create a listener:

BaseDiscoveryListener listener = new BaseDiscoveryListener("_http._tcp", "website", null);

Wait 15 seconds for a service:

listener.waitForFirstService(15000);

Get the first service found:

IServiceInfo service = listener.getFirstService();

Print out some information on the service:

System.out.println("service name: " + service.getName() + " at " + service.getHostAddress() + ", port: " + service.getPort());

Currently there are two implementing backends, one for JmDNS and one for Apple’s mDNSResponder. I would really like to see one written for Avahi, but I probably won’t get to it myself.

The API is in the org.jmdns.api package, which both implementations are in the org.jmdns.impl package. A unit test is also included which demonstrates usage and verifies operation.

I’ve implemented this version within the JmDNS source tree, but ideally the API, JmDNS and mDNSResponder portions of the code would be broken out to be separately distributed, with the JmDNS and mDNSResponder portions functioning as plugins implementing the API.

I’ve only tested this against mDNSResponder 107.5. I’m not sure if Apple’s dnssd.jar is compatible with newer mDNSResponder versions or not.

You can download the full implementation here: jmdns-kiva-1.1.3.tar.bz2

I hope the JmDNS project will pick this effort up and incorporate this into the official release!

This post is just to report that these problems persist in mDNSResponder 108.4. As I reported before, here is what you’ll see when compiling your program:

hidden symbol `__stack_chk_fail_local' in /usr/lib/libc_nonshared.a(stack_chk_fail_local.oS) is referenced by DSO /usr/bin/ld: final link failed: Nonrepresentable section on output

As you can see, its all very intuitive.