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: Lookup Service Discovery using DNS?
Date Sun, 17 Jan 2010 10:17:25 GMT
I've had some thoughts, about p2p distributed lookup, where Services of 
identical Type are responsible for cooperative lookup:

Firstly you lookup a Service by name using DNS-SD, select one of the 
Services in the returned array (perhaps a random algorithm to prevent 
loading up the first service) download its proxy, then:

    * Services of Identical interface Types share some common client
      code, minimizing code download
    * Services with identical fully qualified class names discover each
      other utilizing DNS-SD and using mostly local bytecode, build a
      Set containing proxy's of identical Type, enabling query utilities
      to obtain the correct Service for clients.  Periodically this set
      would be rebuilt, perhaps based upon a Lease?
    * For particularly large collections, this might be broken down into
      a hash range, bounded by a Set's pre-configured maximum size,
      where each service has an overlapping set of proxies.
    * When the Service is the proxy (Smart Proxy), this would put the
      load at the client side, the Smart Proxy might utilize another
      service to assist.
    * The service could have a factory method to return a ServiceQuery,
      getServiceQuery() ,utilizing common code between all services of
      the same Type, with some standard methods shared by all
      ServiceQuery, eg: getServiceInstance(Xuid id) and additional
      methods specific to the service.
    * The server side implementations are free to vary and don't need to
      be disclosed.
    * The client side implementation source code could be publicly
      verified and signed, hence trusted by all parties, any ideas for a
      submission area on River?
    * All Query's would utilize the same openly inspected and signed
      client code.

The caveat is that DNS-SD can't distinguish different types with 
identical names, so either each Type would need to keep some metadata on 
other Type's available with the same name, or simply exclude and ignore 
incorrect Type's.  Then the client would be responsible for checking it 
has the right type.

Penny for your thoughts?


Gregg Wonderly wrote:
> One of the primary issues with the current lookup server design and 
> the ServiceRegistrar interface in particular is the fact that one can 
> only receive unmarshalled services.  My work on providing marshalled 
> results, visible in the http://reef.dev.java.net project, allows the 
> opportunity to find stuff without getting a JVM memory explosion.  
> However, there is a further issue, and that is in order to "see into" 
> the marshalled object you need to either resolve it or dive into the 
> stream of bytes.  My further work on the PreferredClassLoader 
> mechanism for establishing "never preferred" classes helps to make it 
> possible to do resolution of remote objects using locally defined 
> class instances, so that you can, for example, look at Entry objects.
> Also, in my reef work, I investigated adding the names of all classes 
> that are visible in the type hierarchy of the objects so that you 
> could ask "instanceof" kinds of questions without unmarshalling.
> There are just all kinds of issues related to this that come into 
> play. Performing a Jini lookup, on the internet today, would be like 
> asking your web browers to open a tab for every page on the net, and 
> then waiting for that to finish so that you could click through the 
> tabs to find what you are looking for.
> Clearly, lookup needs to be a completely different concept to exist in 
> a large world such as is visible "on the internet."
> Gregg Wonderly
> Peter Firmstone wrote:
>> Anyone got any opinions about Lookup Service Discovery?
>> How could lookup service discovery be extended to encompass the 
>> internet?   Could we utilise DNS to return locations of Lookup Services?
>> For world wide lookup services, our current lookup service might 
>> return a massive array with too many service matches. Queries present 
>> the opportunity to reduce the size of returned results, however 
>> security issues from code execution on the lookup service present 
>> problems.
>> If we did allow queries on a Lookup Service, could we do so with a 
>> restricted set of available Types utilising only trusted signed 
>> bytecodes?  If bytecode becomes divorced from the origin of a 
>> Marshalled Object, and instead obtained from a trusted codebase 
>> service, then perhaps we could have a system of vetting source code 
>> submitted for the purpose of becoming trusted authorised query 
>> types?  Any query utilising untrusted bytecode might return an 
>> UntrustedByteCodeException?
>> Perhaps we could make service match results available as a 
>> bytestream, clients that couldn't handle large amounts of data could 
>> inspect the bytestream, continually discarding what isn't required?
>> Check out this link on DNS service discovery:
>> http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt
>> Cheers,
>> Peter.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message