Sim IJskes - QCG wrote:
On 11/07/2010 12:31 PM, Peter Firmstone wrote:
Sim IJskes - QCG wrote:
On 11/07/2010 07:56 AM, Peter Firmstone wrote:
I've been examining the code relating to discovery, feel free to
clarify
if I've missed some important detail.
River currently has two discovery protocols,
I assuming you talk about internet deployment here. Assuming the
lowest common denominator here, there is no broadcast on the internet.
Exactly, which is why DNS-SD is attractive (not to be confused with
Multicast DNS), making it possible to discover registrar's in different
domains.
Indeed. What your are talking about is a other kind of registry. The
combination of DDNS & DNS-SD.
Yes that's true.
DNS-SD can assist us to discover unknown registrars. DNS-SD would be
used to first discover the host address, port, groups and Service ID of
registrars, then we can use Unicast Discovery to retrieve the lookup
service proxy.
Once you know the ip+port (because you have the queried the dns) you
can construct a proxy of a registrar, can you? No need to do unicast
discovery anymore. Wrong or right?
Wrong, we still need unicast discovery, we can only store a limited
amount of information with DNS-SD, similar to what can be stored in a
single datagram packet. Unicast is needed to retrieve the proxy.
Intranet today:
1. Multicast Discovery
The Internet Tomorrow:
1. DNS-SD
Ok. You did not specify DDNS here, but you meant to include it. Correct?
Correct.
So in order to participate in a specific djinn, you need a
pre-specified registry.
This is currently the situation.
Are you sure? You can currently discover a registry without specifing
a hostname (other then localhost) can you?
Do you still need discovery in this situation?
No you don't need discovery if you already know your registrar. But it's
no longer dynamic either.
Actually this requires a qualification, you no longer require multicast
discovery if you already know where your registrar is, but you still
need unicast discovery to retrieve the proxy, so you still need
discovery, but it lacks the dynamic multicast component. Must have been
tired when I answered it last night.
I'm not fully with you here, the dynamic nature of it, is implemented
in DDNS isnt it?
My general sense of your proposal is dynamic discovery by the use of
DNS-SD + DDNS, and after this another step of discovery. I cannot
place this second step.
The second step is Unicast Discovery (V2) as is currently utilised in River.
DNS-SD + DDNS performs dynamic discovery, to discover the following
information:
/** The lookup service host. */
protected String host;
/** The lookup service listen port. */
protected int port;
/** The lookup service member groups. */
protected String[] groups;
/** The lookup service ID. */
protected ServiceID serviceID;
As currently implemented, Multicast Discovery (V2) is used to discover
this information on an intranet, it is stored in a MulticastAnnouncement
object and used in Unicast discovery to retrieve the registrar proxy.
LookupDiscovery contains DecodeAnnouncementTask, which takes a datagram
packet, creates a MulticastAnnouncement, then uses Unicast to retrieve
the registrar proxy. DecodeAnnouncmentTask's are submitted to a
TaskManager.
From LookupDiscovery's documentation:
* This class is a helper utility class that encapsulates the functionality
* required of an entity that wishes to employ multicast discovery to
* find lookup services located within the entity's "multicast radius"
* (roughly, the number of hops beyond which neither the multicast requests
* from the entity, nor the multicast announcements from the lookup service,
* will propagate). This class helps make the process of acquiring
references
* to lookup services - based on no information other than lookup service
* group membership - much simpler for both services and clients.
Now I'm wondering if the same thing can be done for groups using DNS-SD
& DDNS?
To have several domains participating in a group, a helper utility,
searches DNS-SD records for jini with that group, if clients and
registrar's can authenticate each other, belonging to that group, then
we have a dynamic djinn group that exists on the internet.
An interested user might initially browse groups looking for something
of interest, then dynamically discover all the registrar's in that
group, followed by actual service discovery, filtering by entry, then
performing some more specific local filtering with entry's (with delayed
unmarshalling), followed by unmarshalling a registrar proxy and using it
via a Service UI.
Seems a very powerful concept.
Cheers,
Peter.
