Re: [Nbd] [PATCHv5 0/7] Introduce TLS support on nbdserver & nbdclient

[Alex Bligh <alex@...872...>]

Wouter,

> I'd rather see that the server doesn't spawn a child to do TLS at all,
> as I've indicated before. My long-term plan is to go to a situation
> where the server, at most, spawns a thread for each client (if even
> that). Currently we have a process per client, which take resources and
> is a suboptimal situation.

Sure, I think we'd all rather that.

>   It also means the maxthreads option is to be
> multiplied per client, rather than be a single configuration for the
> whole server.

Actually I would have thought 'per client' would be more useful.

> I'm not saying that fixing that up is a prerequisite for implementing
> TLS,

That's where we got to last time

> but "not making the situation worse" is.

Don't quite understand that.

It doesn't make the situation worse as it is, for non-TLS clients;
they work exactly as currently. It makes the situation infinitely better
for TLS clients!

The bug I refer to isn't really a bug currently, because the hash
table isn't shared across the fork(), so the TLS proxy child is only
ever in the child's hashtable, which isn't shared with the parent or
any other children.

The reason why I fixed it 'properly' was precisely so if you threaded
the whole thing (including the TLS client), we'd not introduce another
problem (I'm assuming the threads would be stored in the hash structure).

We could thread proxy rather than run it as a child - that would be
easy enough I guess?

Of course the right solution would be to rewrite every network
read / write to go via the proxy layer, but that is a big undertaking.

> 
> (obviously the above only applies to the server; on the client, spawning
> a proxy is the only right thing to do)
> 
> [...]
> -- 
> < ron> I mean, the main *practical* problem with C++, is there's like a dozen
>       people in the world who think they really understand all of its rules,
>       and pretty much all of them are just lying to themselves too.
> -- #debian-devel, OFTC, 2016-02-12
> 

-- 
Alex Bligh