svn commit: r50554 - head/en_US.ISO8859-1/htdocs/news/status

Benjamin Kaduk bjk at
Mon Jul 24 23:00:20 UTC 2017

Author: bjk
Date: Mon Jul 24 23:00:19 2017
New Revision: 50554

  Add 2017Q2 CloudABI-based network communication entry from ed


Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2017-04-2017-06.xml
--- head/en_US.ISO8859-1/htdocs/news/status/report-2017-04-2017-06.xml	Mon Jul 24 22:51:32 2017	(r50553)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2017-04-2017-06.xml	Mon Jul 24 23:00:19 2017	(r50554)
@@ -1510,4 +1510,75 @@
       <task>Setup the automatic QA infrastructure.</task>
+  <project cat='proj'>
+    <title>Capability-Based Network Communication for Capsicum/CloudABI</title>
+    <contact>
+      <person>
+	<name>
+	  <given>Ed</given>
+	  <common>Schouten</common>
+	</name>
+	<email>ed at</email>
+      </person>
+    </contact>
+    <links>
+      <url href="">ARPC: GRPC-Like RPC Library That Wupports File Descriptor Passing</url>
+      <url href="">Flower: A Label-Based Network Backplane</url>
+    </links>
+    <body>
+      <p>One of the weaknesses of Capsicum and CloudABI is that it is
+	not easy to develop applications that need to make outgoing
+	network connections, since system calls like
+	<tt>connect()</tt> and <tt>sendto()</tt> are disabled.  Though
+	we can sometimes work around this by ensuring that the
+	sandboxed process already possesses socket file descriptors on
+	startup, this doesn't allow the destination process to be
+	restarted, moved to a different network address, be load
+	balanced, etc.</p>
+      <p>Coming up with a solution for this is quite important for me,
+	as I am currently working on making CloudABI work on top of
+	Kubernetes, Google's open source cluster management suite.
+	The idea is that Kubernetes will schedule CloudABI processes
+	instead of Docker containers.  All of these CloudABI processes
+	will have their dependencies on other services in the cluster
+	injected explicitly, making internal communication very
+	secure.  All of this is intended to work on &os; as well, of
+	course!</p>
+      <p>To solve this problem, I've been working on a daemon called
+	Flower (read: flow-er) that allows software to register
+	services and connect to them.  Servers are identified by a set
+	of labels with values (e.g., <tt>{datacenter: 'frankfurt',
+	service: 'mysql'}</tt>).  Clients can connect these servers by
+	providing the corresponding label(s).  Flower's security model is
+	capability-based, just like Capsicum.  The ability to bind and
+	connect can be limited by permanently constraining labels to
+	certain values.</p>
+      <p>Flower has been designed not to act as a proxy.  It does
+	not copy any data.  It merely forwards existing socket file
+	descriptors or creates UNIX socket pairs and hands these out
+	to its clients and servers.  To realize this, processes
+	communicate with Flower using an RPC library called ARPC.
+	ARPC is a very simple clone of Google's GRPC, with the special
+	feature that messages (Protobufs) can have file descriptors
+	attached.</p>
+    </body>
+    <sponsor>Nuxi, the Netherlands</sponsor>
+    <help>
+      <task>Finish implementing the Flower code.</task>
+      <task>Integrate Flower with the Kubernetes/CloudABI runtime.</task>
+      <task>Release the Kubernetes/CloudABI runtime as open source
+	software.</task>
+    </help>
+  </project>

More information about the svn-doc-all mailing list