river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Discovery - Denial of Service and DNS-SD
Date Sun, 07 Nov 2010 19:47:21 GMT
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.



Mime
View raw message