Re: Revisiting "lost codebases"

        In retrospect, I'd probably have to use some form of a unique global id
in step 1 because two nodes inside a session contacting new nodes will
not tell one another (on opposite ends of the network) about the new
session IDs they just discovered. That is, there would be a potential
for a race condition.

        I was thinking of having the node creating the session encode the id
using his private key, so basically he is saying this "id" is unique
with respect to me. Then if any other node already has such an id but
with respect to another node you know you have a collision. The
remaining question is how you recover from such a thing (as rare as it
might be) keeping in mind that the guy reporting the collision might be
lying. You probably invalidate the node and move on to another node in
the network <shrug> I applied the same mentality in case a node
encounters two versions of the same class within the same session. In
such a case I think you have to drop the "offending node" that
introduces the conflict.

        The problem with assuming that the unique id is signed using a node's
private key is that:

a) You probably don't have encryption capabilities on embedded devices
(though maybe you could talk through a proxy that does)

b) It assumes there is an external party authenticating a public key
with a node.

        I think I'll just assume this is true for now since my target audience
are P2P networks on the desktop so some CA is probably accessible.

Gili

cowwoc wrote:
> Hi,
> 
>         A few months ago I discussed the "lost codebases" problem with you
> guys. I have since put together a system which I hope solves most of the
> existing problems and I would like to get your feedback on it.
> 
>         Start off by forgetting RMI, JINI, etc and imagine a new system being
> designed from the ground up with the following characteristics:
> 
> - When two nodes establish a connection, each assigns a local "session
> id" to the connection and shares that id with its peer. So now each node
> knows about the local and remote session id associated with the
> connection. The idea would be to ensure that nodes retain the same ID if
> their calls boomerang to nodes they have already visited, so as one node
> from an existing session expands the "bubble" to another node which
> isn't yet part of the session he shares all known nodes and associated
> session ids with it. Alternatively, a node initiating a new session
> would generate a globally-unique session id and all subsequent nodes
> joining the session would use that id to communicate with one another
> and when expanding the bubble to new nodes. --- At the time of this
> writing I am not yet convinced I want to go with the unique id approach.
> I don't like the idea that you can't guarantee that the generated UUID
> really is unique. Call me a perfectionist but I'd rather be sure ;)
> 
> - Each local session has a ClassLoader associated with it. Therefore any
> operations that take place within that session get loaded by that same
> ClassLoader.
> 
> - If a node encounters a ClassNotFoundException while trying to execute
> a command on behalf of a remote node, it asks that remote node for the
> class definition. "Effectively rehosting the codebase with each
> transmission hop" as mentioned in section 6.2 of Michael Warres' paper.
> 
> - When a node references a specific class in its communication (such as
> "invoke a method on class C"), it specifies two things: the class name
> and the class version. The class version is currently defined as the
> SHA-1 digest of the class definition (bytecode). The idea is that two
> nodes talking in terms of different versions of the same class will
> "fail fast".
> 
> - Nodes no longer reference classes using codebases hosted on HTTP
> server but rather they transmit class definitions "inline" using the
> main communication protocol. When a class requests a class definition
> the remote host automatically computes all dependent class definitions
> and sends them back over the wire in a single burst (in order to
> minimize multiple back and forth transmissions). This will probably be
> optimized further in the future.
> 
>         Anyway, I think this covers the basics of my proposal. I believe this
> solves the problem of type conflicts because any collection of nodes
> that collaborate on the same operation run within the same session and
> as such run within the same ClassLoader.
> 
>         There are two problems I didn't fully solve:
> 
> 1) Long-term codebase availability. Though I argue this less of an issue
> with my architecture because if the node hosting the service went down
> we have no use for its class definitions.
> 
> 2) Duplication of class definitions if two different sessions load the
> exact same class. I don't know how much of an overhead this really is
> and I suspect this could be optimized further.
> 
> 3) Passing resources over the wire. To my recollection, JINI bundles
> these into JAR files and references them using codebase annotations. I'd
> need to add some sort of mechanism for referencing resources in the future.
> 
>         Anyway, please tell me what you think.
> 
> Thank you,
> Gili
> 
> 
> --------------------------------------------------------------------------
> Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
> Community Web Site:  http://jini.org
> jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
> Unsubscribing:       email "signoff JINI-USERS"  to [email protected]


--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGOxOoIC8Z3eiKRrQRAhgUAJ4wU2MFjhJqxq0nbjV6cU5s4NQtEwCfZYkT
SkcrTaSA0C4E5ZSWfDOXoe0=
=Tw43
-----END PGP SIGNATURE-----