Re: A practical and compelling distributed cap platform: Sandstorm on Cap'n Proto

Hi Thomas,

On Tue, Aug 5, 2014 at 12:24 AM, Thomas Leonard <[email protected]> wrote:

> It wasn't totally clear to me from the page what it actually does.
>

See also: https://github.com/sandstorm-io/sandstorm#how-it-works


>  How
> are the web apps sandboxed? Using VMs? Containers? Processes? Can I
> upload any VM image, like with OpenStack or OpenNebula? If so, how is
> this different?
>

Linux containers. We use the same kernel features that Docker uses. Apps
are packaged in a custom format, but you can build and upload arbitrary
packages.

The main difference from Docker or any of the other things you mention is
that Sandstorm actually has a user interface appropriate for non-technical
users, and an implementation appropriate for running single-user app
instances. Sandstorm containers can scale to the extremely small, such that
it not only makes sense for every user to have their own instance of an
app, but it even makes sense for every document to be a separate instance.

This is accomplished by:
- App instances only run while they're in-use (e.g. while the user has the
app open in their browser). The containers are lightweight enough that they
can start and stop quickly.
- The app code, libraries, and assets are mapped into the container
read-only, such that the files can be shared among all containers running
the same app. Only the /var directory is writable; it contains the
instance-specific data. If done right, the marginal memory overhead of each
new app instance can be kept extremely small, because all the code is in
shared mmap'd pages. (Admittedly that doesn't quite work when the code is
dynamically parsed/compiled at runtime, but we have some ideas involving
checkpointing to solve that.)

Sandstorm further differs from traditional IaaS/PaaS in that it implements
unified authentication and authorization/sharing. If every document is in a
separate sandbox, then Sandstorm can implement access control on the
sandbox, freeing the app from having to worry about it. We can also
implement a Powerbox UI for introducing apps to each other.

We're trying to provide a user-friendly Xen hosting system for users
> to install web-apps on their home routers, developer boards, etc. Our
> plan is for the VMs themselves to be tiny unikernels written in OCaml
> (very little C except for malloc and the boot code):
>
>   http://nymote.org/
>
> Here's an example of a simple web-app I wrote to test it:
>
>   http://roscidus.com/blog/blog/2014/07/28/my-first-unikernel/
>
> I'd certainly like to get some ocaps in here, and the technologies you
> describe sound useful.
>

Is there a Nymote demo somewhere, similar to demo.sandstorm.io? I have seen
Nymote a few times but I admit I've have trouble forming a mental model of
what it does without being able to use it. What kind of apps are available
on it today?

One thing I've wondered: How easy is it to take an existing app written in,
say, PHP or Node.js, and run it on Nymote?


> How did you fix the DoS problems we had with pipelining in E?
>
> (being able to use lots of resources on a server by doing bignum
> calculations on ints, making millions of copies of strings and lists,
> etc)


Cap'n Proto does not implement mobile code, so the client is limited to
calling the things the server exports. To create a bignum or perform ops on
in, the server application would have to explicitly expose an interface for
doing these things.

That said, there are certainly resource exhaustion attacks possible
currently. We have more work to do here.

-Kenton

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk