DNS-SD

[Peter Firmstone <ji...@zeus.net.au>]

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.

Re: DNS-SD

[Peter Firmstone <ji...@zeus.net.au>]

A warm welcome to you Zoltan, I'd definitely be interested in your 
findings and would be very happy if you or any of your students wanted 
to participate in Apache River.

We've added a StreamServiceRegistrar interface, still open for review of 
course, so it will probably receive some refactoring before it becomes 
part of a release.  Delayed proxy unmarshalling (selected Entry's are 
unmarshalled) and handling of results in small batches (hence Stream) 
are key to the new interface.  The motivation is to reduce the burden on 
the network and client, while allowing the client greater flexibility in 
filtering unwanted services.

https://svn.apache.org/repos/asf/incubator/river/jtsk/trunk/src/net/jini/core/lookup/

DNS-SD might assist to define arbitrary network ports for jini 
discovery, it might be useful for having multiple internet facing 
Service Registrar's on a firewall with one IP address, each port is 
NAT'd to some other box behind the firewall, DNS-SD would allow you to 
use Unicast to contact the Service Registrars.  

Thanks for the tip on network load, your definitely right, I'm concerned 
about that too.

Daniel Steinberg took the liberty some time ago of registering "jini" in 
the list of DNS-SD service types:

http://www.dns-sd.org/ServiceTypes.html

The type description on dns-sd.org allows for any arbitrary Jini 
service, based on interface names.  However I'm starting to consider 
DNS-SD suitable only for dynamic arbitrary assignment of port numbers 
for jini-discovery.

from http://www.iana.org/assignments/port-numbers

#			   Dave Wierbowski <wierbows&us.ibm.com> August 2006
jini-discovery  4160/tcp   Jini Discovery
jini-discovery  4160/udp   Jini Discovery


For services behind firewalls, Sim IJskes is working on "Meekong" a Jeri 
endpoint with a relay, or listening post (static ip) to enable services 
to cooperate from behind firewalls.

Later I'd also like to work on a mediator that connects endpoints from 
behind firewalls, where ports on the firewalls are opened by 
simultaneous outgoing connections and firewalls are tricked into routing 
packets between the service and client.  This has been demonstrated by a 
researchers, for TCP, this and the former methods are referred to as 
STUN, TURN and ICE.

Best Regards,

Peter Firmstone.

Zoltan Juhasz wrote:
> 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.
>
> Cheers,
>
> Zoltan
>
> =================================
> 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
>>
>>
>>     
>
>
>   

RE: DNS-SD

[Zoltan Juhasz <ju...@irt.vein.hu>]

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.

Cheers,

Zoltan

=================================
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
> 
>