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:[email protected]]
Sent: 21 June 2010 12:13
To: [email protected]
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
