Recent changes to feature-requests

Jmmdns Interface

2011-12-27T00:00:40Z

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 :)

Support Discovery of Browsing and Registration Domains (Doma

2010-11-15T21:47:13Z

One of the motivations for DNS-Based Service Discovery is so that
when a visiting client (e.g. a laptop computer) arrives at a new
network, it can discover what services are available on that network
without manual configuration. This logic (discovering services
without manual configuration) also applies to discovering the domains
in which services are registered without requiring manual
configuration.

This discovery is performed recursively, using Unicast or Multicast
DNS. Five special RR names are reserved for this purpose:

b._dns-sd._udp.<domain>.
db._dns-sd._udp.<domain>.
r._dns-sd._udp.<domain>.
dr._dns-sd._udp.<domain>.
lb._dns-sd._udp.<domain>.

By performing PTR queries for these names, a client can learn,
respectively:

o A list of domains recommended for browsing

o A single recommended default domain for browsing

o A list of domains recommended for registering services using
Dynamic Update

o A single recommended default domain for registering services.

o The final query shown yields the "legacy browsing" or "automatic
browsing" domain. Sophisticated client applications that care to
present choices of domain to the user, use the answers learned
from the previous four queries to discover the domains to present.
In contrast, many current applications browse without specifying
an explicit domain, allowing the operating system to automatically
select an appropriate domain on their behalf. It is for this class
of application that the "automatic browsing" query is provided, to
allow the network administrator to communicate to the client
operating systems which domain(s) should be used automatically for
these applications.

These domains are purely advisory. The client or user is free to
browse and/or register services in any domains. The purpose of these
special queries is to allow software to create a user-interface that
displays a useful list of suggested choices to the user, from which
the user may make a suitable selection, or ignore the offered
suggestions and manually enter their own choice.

The <domain> part of the Domain Enumeration query name may be
"local." (meaning "perform the query using link-local multicast) or
it may be learned through some other mechanism, such as the DHCP
"Domain" option (option code 15) [RFC 2132] or the DHCP "Domain
Search" option (option code 119) [RFC 3397].

The <domain> part of the name may also be derived from the host's IP
address. The host takes its IP address, and calculates the logical
AND of that address and its subnet mask, to derive the 'base' address
of the subnet. It then constructs the conventional DNS "reverse
mapping" name corresponding to that base address, and uses that
as the <domain> part of the name for the queries described above.
For example, if a host has address 192.168.12.34, with subnet mask
255.255.0.0, then the 'base' address of the subnet is 192.168.0.0,
and to discover the recommended automatic browsing domain for devices
on this subnet, the host issues a DNS PTR query for the name
"lb._dns-sd._udp.0.0.168.192.in-addr.arpa."

Sophisticated clients may perform domain enumeration queries both in
"local." and in one or more unicast domains, and then present the
user with an aggregate result, combining the information received
from all sources.

Built-in support for multiple network interfaces

2008-04-07T05:39:29Z

There are two related problems I have noticed:
* If you have a machine with two network interfaces (lately a large number of motherboards have started to come with dual network ports), JmDNS' default factory method may pick the wrong one.
* Even if you only have one physical network interfaces, installing VMware can often result in the same symptom.

The current workaround for this is to create one JmDNS per interface, and manage all of them -- when you need to publish a ServiceInfo you need to publish it on all of them, and what happens if two of them are actually on the same network? Presumably hell breaks loose, although I am yet to find out.

Unfortunately this workaround is not very simple, as ServiceInfo does contain the IP address so you actually wind up adding multiple independent ServiceInfo records to advertise the existence of a single host.

It would be nice if JmDNS itself would provide the built-in ability to listen on multiple interfaces, or at the very least multiple IP addresses, such that we can pass in a list of NetworkInterface or a list of InetAddress, and have it Do The Right Thing [TM]. Ideally it would also need to support adding and removing interfaces at run-time, as realistically the state of the network does change at runtime.

Add subtypes

2006-10-23T11:56:28Z

The DNS SRV TXT extension documents
(http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt)
names the possibility to add subtypes to a given DNS-SD
instance - it seems that JmDNS still lacks the support
for it. It would be nice to have the option to register
(and browse for) service subtypes as well.

Maven depository update

2006-02-16T07:11:28Z

I'd like the Ibiblio.org Maven2 repository updated to
the latest version. Current version at
http://www.ibiblio.org/maven2 is version 0.2.

Kind regards,
Roland

Support ability to register proxy services

2004-08-09T05:22:38Z

JmDNS should be able to act as a proxy service registry, for
services running on another host than the JmDNS instance.

Thoughts about the implementation:
------------------------------------------
This may require that JmDNS provides a registry for HostInfo's.
The registry may be handled behind the scenes by JmDNS, or we
can make it part of the API.

This registry shall be used to publish on the network the names for
all hosts, for which JmDNS has ServiceInfo's.

Thus, we may have to add a class named HostInfo.
The class HostInfo shall have the following constructors:

/**
* Construct a host description for registrating with JmDNS.
* @param unqualified host name, such as <code>foobar</code>.
* The host name is extended by JmDNS to foobar.local.
* JmDNS may change the host name at any time, to
* resolve conflicts.
* @param addr the address to which the host is bound.
*/
public HostInfo(String hostname, InetAddress addr)
/**
* Construct a host description for registrating with JmDNS.
* The host name is generated by JmDNS using an RARP request.
* JmDNS may change the host name at any time, to
* resolve conflicts.
* @param addr the address to which the host is bound.
*/
public HostInfo(InetAddress addr)

The following methods shall be added to JmDNS:

public void registerHost(HostInfo info)
public void unregisterHost(HostInfo info)

A HostInfo parameter shall be added to the constructors of
ServiceInfo:

public ServiceInfo(String type, String name, HostInfo host, int
port, String text) {

Alternatively, if we don't want the host registry to be part of the
API, we can make class HostInfo and all associated methos
package privete. In this case an InetAddress parameter could be
added to the constructors of ServiceInfo. JmDNS would generate a
HostInfo instance and register it behind the scenes.

public ServiceInfo(String type, String name, InetAddress addr, int
port, String text) {

J2ME CLDC version

2004-05-13T19:16:10Z

It will be really nice to have a J2ME CLDC version of
JmDNS.

Using unqualified service names in the API

2004-02-08T13:30:17Z

The API of JmDNS always uses two parameters '(qualified) name'
and 'type' to identify a service instance.

i.e. to register a service with the unqualified name 'My Service'
and of type '_http._tcp.' one has to create a ServiceInfo object
using the following parameters:

new ServiceInfo( "_http._tcp.", "My Service._http._tcp.", ...);

The qualified name and the type are redundant to some extent.
This leads to confusion (well, at least this confuses me).

The API would be easier to understand, if it either used only one
parameter (the fully qualified name) or two non-redundant
parameters (the type and the unqualified name).

Since parsing a fully qualified name may not be possible, (i.e.
when the unqualified name contains dots '.'), I am in favor for
using the type and the unqualified name.

After implementation of this RFE, to register a service with the
unqualified name 'My Service' and of type '_http._tcp.' one would
create a ServiceInfo object using the following parameters:

new ServiceInfo( "_http._tcp.", "My Service", ...);

Note: The implementation of this RFE will affect all public methods
of JmDNS, which use 'type' and 'name' as parameters.

IPv6 support?

2004-02-04T13:11:30Z

It seems that this doesn't support IPv6? However both
Java 1.4 and mDNS drafts support IPv6.

I would like to use JmDNS in my IPv6-only wireless
network. When will we see full IPv6 support?

listing available services of a given type

2003-12-31T14:05:19Z

It would be nice, if JmDNS could list all services of a given
type. The current implementation requires the registration
of a ServiceListener. Having a list(String type) method
would greatly simplify the amount of programming needed
to do this.

I am thinking of a method similar to the one of Interface
java.rmi.registry.Registry:

Here's how the method signature could look like:

/**
* Returns all available service informations of the specified
* type.
*
* @param type full qualified service type, such as
_http._tcp.local..
* @return An array of service information objects.
* Returns an empty array if no service informations can be
* obtained. Never returns null.
*/
public ServiceInfo[] list(String type);