river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zoltan Juhasz" <juh...@irt.vein.hu>
Subject RE: DNS-SD
Date Mon, 21 Jun 2010 11:26:13 GMT
Hi Peter,

I have been absent from the Jini developments for some years, so I'm not
100% up-to-date on where you are with Internet-wide service discovery. About
5-6 years ago we did work on this issue within the JGrid project and came up
with the idea of a multi-layer hierarchical discovery infrastructure. As we
were working on Jini-based Grid systems, we called it a Grid Access Point
(GAP). The role of GAP and router layer was to hide the registrars and only
allow services out that were tagged as 'global'. We used the hierarchy to
aggregate service information so we could achieve content-based routing in
the system during discovery; your lookup queries would only go to areas
where there is a chance of finding a suitable service. We used both the
interface and various attributes in this routing. One problem we bumped into
was going through firewalls -- which might be solved by then -- and the
strict hierarchy. I was planning to extend this system to a fault-tolerant
ovelay network (using some P2P extension) with a PhD student but never
really got to this point. 

I'm not sure the DNS would be a right place to do anything like this.
Networking folks are very sensitive to adding anything to the core
networking infrastructure that would affect its performance, etc. 

If you think our work is of any interest, I can dig up papers and discuss it
further on the list.



Dr Zoltan Juhasz
Dept of Electrical Engineering and Information Systems
University of Pannonia (formerly University of Veszprem)
Veszprem, Hungary


> -----Original Message-----
> From: Peter Firmstone [mailto:jini@zeus.net.au] 
> Sent: 21 June 2010 12:13
> To: river-dev@incubator.apache.org
> Subject: DNS-SD
> Any one have any thoughts about DNS-SD for River's Services 
> over the internet?
> I'm wondering if DNS-SD should only be used for discovery of 
> Registrars or whether it should include the ability to locate 
> all Jini Services?
> I'm leaning towards discovery of Registrars only.
> Perhaps an Internet facing Registrar might only allow for 
> Services to be looked up, or to notify new registrations, 
> external services shouldn't be able to register with any 
> particular domain Registrar they like?  
> Then when you think about mobile devices, with dynamic ip 
> addresses, you'd want them to be able to register with some 
> static ip assigned Registrar, in order to be locatable.
> Then when you think about devices that cannot utilise a 
> service, but can provide one, then how should they advertise 
> the presence of their service?  They need to provide a 
> downloadable implementation of a Service Registrar, fully 
> contained within a smart proxy.
> So really there is this possibility that we might be dealing 
> with immutable Registrar's, where notify might be used to 
> notify a client that a services location had changed, but 
> register is ignored.  This does however present a problem to 
> services trying to register with an immutable Registrar, 
> Services will continue to try to register, there is no 
> behaviour specified to reject registration, other than to 
> throw a RemoteException, followed by another attempt to register.
> It seems an Internet Registrar would need to share a common 
> super interface with Service Registrar, but also have the 
> ability to reject a registration?  Perhaps a ServiceRegistrar 
> compatibility layer might redirect a registration destined 
> for an internet Registrar to a local domain Registrar with an 
> identical group name?
> Any ideas / thoughts?
> Cheers,
> Peter.
>  _____________ NOD32 5213 (20100621) Információ _____________
> Az üzenetet a NOD32 antivirus system megvizsgálta.
> http://www.nod32.hu

View raw message