Peter Firmstone wrote:
Peter Firmstone wrote:
Peter Firmstone wrote:
Sim IJskes - QCG wrote:
On 11/08/2010 12:39 PM, Peter Firmstone wrote:
Seeing as we're not interested in Multicast DNS, we're probably
better
off utilising Waiter's source and integrating only the
functionality we
need into River. I'll ask the original author if he's happy to donate
some code.
Or http://www.dnsjava.org/, BSD license, recently updated project.
Used by james.
Gr. Sim
Much better, we don't need to maintain it and can distribute it with
river as a library.
Cheers,
Peter.
Rather than use jini as the service type, which has already been
defined by Daniel Steinberg for any arbitrary Jini service, do you
think we should use jini-discovery as per IANA's service type
definition?
jini-discovery 4160/tcp Jini Discovery
jini-discovery 4160/udp Jini Discovery
# Mark Hodapp <mark.hodapp&sun.com>
DNS-SRV service type:
jini-discovery
http://www.dns-sd.org/ServiceTypes.html
Meaning that in the internet, any port can be used for discovery,
provided that the "jini-discovery" DNS-SRV service type is used in DNS
records.
Thoughts?
Peter.
LookupLocator is used by LookupLocatorDiscovery as little more than a
String URL parser, to store the host and port information.
ConstrainableLookupLocator extends LookupLocator to support Discovery V2.
For DNS-SRV we could have a utility that searches DNS-SRV records and
creates ConstrainableLookupLocator instances for each record. We'd have
to specify constraints for the utility to set.
Currently the Discovery and Join spec requires a jini://host:port/ or
jini://host/ syntax for URI's, if no port is specified, the default is used.
Cheers,
Peter.
