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.
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?
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?
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.
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.
Gr. Sim
