Re: Mirari template

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

Running the SSL proxy in daemon mode fits in well with the Fable API that 
Jeremy has been adding to Cohttp.

Fable separates connection establishment from ongoing data transfer, and so the 
first phase is where all the SSL negotiation and verification happens.  This 
means that an app could spin up a persistent stud client daemon upon the first 
SSL connect, and re-use it as appropriate.  Or, to be a little more exotic, a 
Mirage VM could delegate SSL communication to a stub domain running OpenSSL, 
until we get our own native OCaml implementation.

I notice a Cohttp pull request has appeared in my queue, so I'll merge it and 
report back!

-a

On 2 Apr 2013, at 11:26, Dave Scott <Dave.Scott@xxxxxxxxxxxxx> wrote:

> Ok sounds good!
> 
> In the existing code we made a mistake by running stunnel in "stdin/stdout" 
> mode. We didn't realise it at the time but this prevents the use of TLS 
> session caching which (IIRC) reduces the number of round-trips needed to make 
> a new connection which has a massive impact on connection setup latency. 
> Running in "daemon" mode where you forward all connections from a local 
> socket to a remote allows caching, and is the common most well tested code 
> path. Unfortunately last time I looked you could only forward from local ip 
> ports where you had to manage the port number space yourself-- this turned 
> out to be tricky since it was difficult to tell from stunnel's output whether 
> it had succesfully bound to a given port or not. Ideally it would allow one 
> of:
> 
> 1. forwarding from a unix domain socket path (where the space of file names 
> is easy to control)
> 2. inheriting an already-bound socket via fork() inheritance or explicit 
> message passing
> 3. A option to bind an arbitrary local port and let us know which one it was
> 
> My general concern with stunnel is that I think it's meant for more static 
> configurations where you just run one in front of your web server. It might 
> not be best suited for more dynamic stuff where tunnels are coming and going 
> all the time.
> 
> We could take a look at "stud" -- the Simple TLS Unwrapping Daemon -- and see 
> how it compares.
> 
> Cheers,
> -- 
> Dave Scott
> 
> On Apr 2, 2013, at 1:06 AM, "Anil Madhavapeddy" <anil@xxxxxxxxxx> wrote:
> 
>> Given Vincent is using Core now, I think that a rewrite is easiest. There's 
>> an Async.Shell which should fit the bill nicely.
>> 
>> -a
>> 
>> On 1 Apr 2013, at 07:35, Dave Scott <Dave.Scott@xxxxxxxxxxxxx> wrote:
>> 
>>> It'll need extraction, and by that I mean a combination of both moving the 
>>> code and partially rewriting it...
>>> 
>>> -- 
>>> Dave
>>> 
>>> On Mar 31, 2013, at 11:47 PM, "Anil Madhavapeddy" <anil@xxxxxxxxxx> wrote:
>>> 
>>>> Sure; Jeremy (CCed) is improving Cohttp+Async support, so depending on it
>>>> for the host tools is fine.  Best use it everywhere in Mirari though, if
>>>> you use it at all.
>>>> 
>>>> The one missing thing in Cohttp/Async is SSL support, which we'll need to
>>>> add via an stunnel wrapper for now. Dave, is the existing Xapi stunnel code
>>>> in a library, or do we need to extract it?
>>>> 
>>>> -anil
>>>> 
>>>> On 31 Mar 2013, at 14:41, Vincent Bernardoff <vb@xxxxxxxxxxxxxx> wrote:
>>>> 
>>>>> On 31/03/2013 14:22, Vincent Bernardoff wrote:
>>>>>> On 31/03/2013 14:14, Vincent Bernardoff wrote:
>>>>>>> Hello,
>>>>>>> 
>>>>>>> Today I tried to use templates to generate the main.ml with Mirari
>>>>>>> instead of putting the source code as strings in the program.
>>>>>>> 
>>>>>>> You can checkout git://github.com/vbmithr/mirari branch template.
>>>>>>> 
>>>>>>> Basically, I added a template/main.ml file which is an OCaml file (the
>>>>>>> former generated main.ml) with optcomp directives in it.
>>>>>>> 
>>>>>>> Mirari has been modified to output a settings.ml file instead, that is
>>>>>>> included by the templated main.ml.
>>>>>>> 
>>>>>>> I don't know if it is useful or not, I just started that because I
>>>>>>> didn’t like very much the idea to have the generated code embedded in
>>>>>>> mirari.ml, and that I needed to modify it to experiment a bit with the
>>>>>>> UNIX backend.
>>>>>>> 
>>>>>>> What do you think about it, if anything ?
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> Vincent
>>>>>> 
>>>>>> Just remembered why I did that in the first place: I want the
>>>>>> autogenerated main.ml have a different code according to the backend as
>>>>>> well, just in case it would be needed. For example, I don’t want to use
>>>>>> the Net.Manager for UNIX.
>>>>>> 
>>>>>> Vincent
>>>>> 
>>>>> Ok to use Core in mirari/mirage, BTW ?
>>>>> 
>>>>> Vincent
>>>> 
>>>>