Re: Object Capability model for IoT

David Barbour <[email protected]>
Newsgroups gmane.comp.capabilities.general
Message-ID <CAAOQMSu0muc-oR5yC7LVdu6ZJ1=ZGuyPfH-k7uVJkcteeX_S=Q@mail.gmail.com>
On Mon, Jun 23, 2014 at 12:58 AM, Rob Meijer <rmeijer-qWit8jRvyhVmR6Xm/[email protected]> wrote:

>
> Could you elaborate on when/why using random strings would induce the need
> for distributed garbage collection?
>
>
Conditions: we represent capabilities with random strings in an open
distributed system, and we can transfer these capabilities between
different vats (or hosts, services, etc.).

Under these conditions, a vat must maintain a table associating random
strings to local objects (or actors, functions, etc.). Further, this table
must be global because a capability might be transferred between vats
before invocation.

In practice, an association table growing without bound would be
problematic. So we would need some way to determine that a random string
will no longer be invoked... i.e. garbage collection. In a distributed
system, this garbage collection will be distributed.

If we instead use meaningful strings (which might be encrypted or protected
by HMAC) we can avoid creating the association table and instead encode an
association directly in the string - i.e. such that there is a more
meaningful computation of the capability itself. The extreme form is to
encode whole objects or closures into a string, but there are many
intermediate forms.

It is feasible, instead of GC, to use expirations or manual destruction.
The latter introduces its own challenges - a lot of extra state that can go
wrong in case of partial failure or network partitioning. And expirations
are usually not very compositional, though I leverage them in a constrained
setting where I can easily replace the expiring capabilities (via
dataflow). But even for those volatile capabilities, I find a lot of value
in using meaningful strings and minimizing use of association tables.

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.