Re: generalising oxenstored for unix nodes too

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 15 Feb 2012, at 14:19, Raphael Proust wrote:
> 
> There are some early experiments at https://github.com/avsm/ocaml-ld
> 
> In the ARP example
> (https://github.com/avsm/ocaml-ld/blob/master/examples/arp-fast/arp.ml), the
> query function has type
> val query: ?timeout:float -> ipv4_addr -> ethernet_mac option Froc_sa.t
> 
> It means that the result of a query is not a static mac address it's a
> changeable (Froc_sa.t, sa stands for self-adjusting) one. Hence one can build 
> a
> value that depends on this address. Such a value is guaranteed to be 
> recomputed
> whenever the ARP entry associated with the queried IP address changes.
> 
> Thus you can open a TCP connection and be given a closure. The actual code
> executed when calling is updated so has to fill the packet headers (and among
> them the MAC destination field of the ethernet frame) correctly.

The missing API end-point here is what the application API looks like, which
is (coincidentally :) quite similar to the FABLE flows described in:
http://anil.recoil.org/papers/2012-resolve-fable.pdf

So the idea is that every I/O flow is established as a series of FRP variables
that record all the various stacks that it depends on, with the result being
a buffer pool that the application can write into.  This buffer pool can be
adjusted as a result of a change in the underlying channel (i.e. a live 
migration), which should be invisible to the application.

There are some details to work through, such as where all these I/O flows are
registered (hence my looking at oxenstored), and also precisely what the 
reconfiguration API provides (i.e. where is the policy for 'old' to 'new'
transition, which might involve killing existing connections, or letting 
existing ones continue until they terminate, and so on).

-anil