A global registry, interesting, I like it.
Sim, your right, we probably don't need another multicast protocol, but
bonjour does more than just multicast, if they're achieving opening of
firewall ports it might be tempting to utilise, if available. From
Apple's web site FAQ at
http://developer.apple.com/networking/bonjour/faq.html :
3. Does Bonjour work between multiple subnets?
Yes. The first release of DNS Service Discovery [DNS-SD
<http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt>] for Mac
OS X concentrated on Multicast DNS [mDNS
<http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt>]
for single-link networks because this was the environment worst
served by IP software. Starting in Mac OS X 10.4, Bonjour now uses
Dynamic DNS Update [RFC 2316 <http://www.ietf.org/rfc/rfc2136.txt>]
and unicast DNS queries to enable wide-area service discovery.
This port is registered with IANA for DNS:
jini-discovery 4160/tcp Jini Discovery
jini-discovery 4160/udp Jini Discovery
# Mark Hodapp <mark.hodapp&sun.com>
DNS SRV (RFC 2782) Service Types at
http://www.dns-sd.org/ServiceTypes.html contains this service entry:
jini Jini Service Discovery
Daniel Steinberg <daniel at oreilly.com>
Protocol description: Convention giving a
deterministic programmatic mapping
between Jini service interface names and subtypes of
the DNS-SD service
meta-type "_jini._tcp". For example, a client wishing
to discover objects
that implement the "com.oreilly.ExampleService"
interface would broswse for
the DNS-SD service subtype
"ExampleService.oreilly.com._sub._jini._tcp".
(Note: Using Apple's Bonjour programming API, service
subtypes
like this are expressed as a comma-separated list
following
main type, e.g. "_jini._tcp,ExampleService.oreilly.com".
This allows an object that implements several
interfaces to specify
all of those interfaces in a list when it registers
its service.
When browsing for services, at most a single subtype
is allowed.)
Defined TXT keys: None
I like the idea of maintaining Reggie islands and not having Reggie
replicate itself, it would be up to Reggie to register itself with a
Global Registry Service (in case Reggie instances want to remain
anonymous). Clients might report timeouts back to the global registry.
The Global Registry might then preference order its returned result
based on client feedback and some degree of randomness, so that second
try's return a different Registry.
We'd need a very simple interface, more accurate type matching by
comparing marshalled object instances can be left to Reggie itself,
Services looking to register themselves with number of Reggie instances
might repeat the request multiple times:
public interface GlobalRegistry {
public URI getLookupService(String fullyQualifiedServiceClassName);
public void reportLookupServiceTimeout(URI reggie);
/* Idempotent if the messageDigest hasn't changed, protected by a
security check based on a pgp web of trust and a
* Message Digest that confirms the message details haven't changed in
transit.
* The first string in the Array should be a URI / URL, the remaining, a
list of fully qualified class names of service
* types, also containing super types.
*/
public void registerLookupService( String[]
uriAndFullyQualifiedServiceClassNameList, String messageDigest);
}
Cheers,
Peter.
[email protected] wrote:
Just out of curiosity, why wouldn't it be taken on as a project within
this group to do:
a) Create an enhanced specification for Reggie to allow it to act as a
global registry with sufficient permissions and scope.
b) Create a new service which sole purpose is to act as a global
registry.
Either of these can be accomplished within the current River framework.
Regards,
Martin
On Jan 12, 2010, at 620AM, Sim IJskes - QCG wrote:
Dennis Reedy wrote:
On Jan 12, 2010, at 557AM, Sim IJskes - QCG wrote:
Peter Firmstone wrote:
Anyone got any opinions about Lookup Service Discovery?
How could lookup service discovery be extended to encompass the
internet? Could we utilise DNS to return locations of Lookup
Services?
For world wide lookup services, our current lookup service might
return a massive array with too many service matches. Queries
present
the opportunity to reduce the size of returned results, however
security issues from code execution on the lookup service present
problems.
I haven't seen any world wide deployments yet, at least not on my
bench. :-) And i would like to reserve my definite judgement before i
have had an actual production deployment of such a service.
As i understand it, reggie will replicate information between its
peers.
Reggie does no such replication.
That makes it easier to create islands! :-)
I've had 2 reggies running, and the service was registered on both of
them (if i remember correctly), so this was the clients doing?
Yep
