[coyotos-dev] On distributed systems

Tom Bachmann e_mc_h2 at web.de
Wed Feb 1 13:26:35 EST 2006


Dominique Quatravaux wrote:
> Tom Bachmann wrote:
> 
> 
>>I have been thinking about how to build transparent "distributed
>>capabilities"
> 
> 
> You should have a look at
> http://www.erights.org/elib/capability/ode/ode-protocol.html (and the
> rest of the site while you are there :-).
> 

Great. I somewhat reinvented it. :(

> 
>>The basic idea is to have a trusted object on every machine that
>>forwards requests over the net.
> 
> 
> Correct (there can be several per machine; they are called "vats" in E)
> 

So those "vats" have to communicate?
Anyway, I think this is a minor detail.

> 
>>The cap itself is probably encrypted or something like this,
> 
> 
> It doesn't need to. the identity of a remote machine comprises a public
> key,

Agreed.

> and the pointer to the exact object is simply a random secret
> number of 80 bits or more (therefore unguessable)

I'm not too familiar with this cryptography stuff, but 2 ** 80 sounds 
comlex enough.

> 
> Separating activation from data
> moving, as discussed last week for Coyotos,

What have I missed?

> is not helpful in the
> networked case due to latency considerations (you want to do as much as
> possible in one network round-trip).
> 

agreed. This was just an expliaction artifact.

> 
>>Actually, the forwarder is the only object in the system that has to
>>deal with the difference between real local capabilities and logical
>>remote ones. 
> 
> 
> Depends on how one is supposed to handle network outages, and also on
> performance considerations. Under E, everybody knows the difference.
> 

With performance considerations you mean the measurable different 
latencies when invoking local/remote caps?
I think one of the nice things with a transparent solution is that 
applictions don't see any difference, hence there is no special handling 
needed. Still the forwarder or vat(s) could offer to reveal "logical 
remote capabilities".
-- 
-ness-


More information about the coyotos-dev mailing list