[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] Update on capnp-rpc



> 1. The fuzz tests found a race, where messages may get delivered out
> of order in some (convoluted) cases.
> I asked on the capnp list, and it seems that the C++ reference
> implementation doesn't handle this quite right either.
> We're investigating a fix, but it's unlikely you'll hit the problem.
> See: https://github.com/mirage/capnp-rpc/issues/59

Being able to run fuzz-testing on a complex RPC protocol is really great! The 
bug that it founds look also quite involved :-)

> 2. The API for building requests and responses has a lot of
> boilerplate. I'd like to simplify this by modifying capnp-ocaml to
> allow attaching capabilities to messages without requiring a separate
> type.

I have been using the library quite a lot recently and indeed there is a lot of 
boiler-plate. Generating more code seems indeed sensible. 95% of the 
client/code is type-driven so I am pretty sure we could auto-generate almost 
everything with a few annotation to select the right calling convention for 
instance (to switch between call_for_value and pipeline calls).

My latest experiment is to generate client/server bindings for some MirageOS 
signatures:

https://github.com/linuxkit/linuxkit/blob/master/projects/miragesdk/src/sdk/proto.capnp

and see the (verbose) client/server code for Mirage_flow_lwt:

https://github.com/linuxkit/linuxkit/blob/master/projects/miragesdk/src/sdk/flow.ml
 
> 3. There are some (minor) Unix dependencies in the library and in
> capnp-ocaml, which need moving out so we can use it in unikernels.
> 
> 4. Start on level 2 support, which will require the library to be able
> to establish secure connections. Currently, it doesn't do any crypto
> and so the helpers only allow connections over Unix-domain sockets for
> now.
> 
> I'd be interested in feedback from anyone who wants to try it!

Thanks for doing that work, I really like 1st class support for passing around 
functions. It fits very well with turning a random MirageOS signature into an 
RPC boundary. I really would like to use this to define MirageOS groups of 
unikernels coordinating via secure RPC over the MirageOS signatures -- I have 
plans to extend the mirage tool to do this (or at least try) at one point :-)

Best,
Thomas
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.