Re: Mirari template

[Dave Scott <Dave.Scott@xxxxxxxxxxxxx>]

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
>>> 
>>>