Re: [Openvpn-users] latency issues on larger scale OpenVPN setup

[Samuli S. <sa...@op...>]

>> The challenge with OpenVPN is that redesigning a single-threaded
>> application to become a multi-threaded one is not as easy as it often
>> sounds like.  And you would actually be able to manage pretty much the
>> same result as if you would just do it in a single thread.  If OpenVPN
>> would just defer the waiting while re-keying, taking care of some other
>> connections in the mean time, this would solve this lag.  And without
>> having looked too much at the previous attempt, I believe this was what
>> it was trying to do.  But this approach makes it tricky, as the re-keying
>> might be prune to fail if the further RSA process is postponed for too
>> long.  And this could happen in a large site, with many active VPN
>> clients pushing data.
>>
> Let me play the devil's advocate here.. what if the current approach -
> single-threaded but multiple processes - makes more sense than going
> multi-threaded? Threads are lighter than processes, but also make the
> code more complex (and error-prone). Do we get any other benefits from
> threads besides better utilisation of multiple processor cores?
>
I might add that use of threads makes sense if single client connections
waiting for I/O block other clients too often (topic of this thread). In
this case isolating each connection is useful, and threads are quicker
and less computing-intensive to create than processes.

Besides the client initialisation/key renegotiation are there other
places where the whole OpenVPN process could get blocked by a single client?

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock