On Thu, Aug 7, 2014 at 4:56 AM, David Sommerseth
<openvpn.l...@topphemmelig.net> wrote:
>
> However, that is most likely less intrusive and complex than to
> basically needing to re-write the event handler which schedules that
> each client gets their "time slice" in OpenVPN. OpenVPN's event
> handling the only thing which makes OpenVPN tackle more clients at the
> same time, inside the same process/thread.
I don't see why you'd need to change that at all. Let the parent
process continue to handle all of the client connections, and just add
a socket to the child process(es) into the event loop. Then instead
of recomputing the keys in the parent, send that work over the socket
to the child, which, being a fork, already has the same event handler.
I think the only extra complexity would be having to track 'work
pending' connection states until the child returns the completed work.
> The OpenVPN implementation is also quite different from your apache
> pre-fork suggestion, where the connection to a web server is closed
> after having served a simple request with limited amount of data.
Agreed - I wouldn't have the child processes accept any connections.
The similarity would only be in managing a pool of worker processes.
But for simplicity consider just one forked child where you hand off
rekeying. You'd probably really want a pool of connections to
workers, but even one would double the CPU power available and avoids
the complexity of balancing a pool.
>Likewise, if you have 100
> clients connecting 10 times retrieving data in parallel, this also is
> a stressful moment for the web-server. This doesn't happen in
> OpenVPN, because each client gets a "time slice" before OpenVPN serves
> others again.
Right, but if you keep that same logic but fork the process and push
the packets that involve a lot of CPU work to a different instance you
get time slices out of multiple CPUs instead of just one.
> The complexity of implementing a pre-forked model would actually be
> far more complex than the alternative. And in addition, there is a
> need for a SSL state manager, which keeps tracks of the SSL keying
> material for each client, no matter which approach is used. OpenVPN
> does already have such a state manager, but it's fairly simple because
> it only needs to process each request one client by one client.
A forked copy would automatically have the same management code...
And you'd have the option of either passing any needed state over the
socket between processes or using explicitly shared memory and some
sort of lock to arbitrate access- which you'd need with threads
anyway. There would be some extra overhead in passing things over
the sockets, but you might have 2 to 32x the CPU power to do it.
--
Les Mikesll
lesmikes...@gmail.com
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
