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?
Peter.
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.
