On 07/08/14 16:15, Les Mikesell wrote: > 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.
If I were to add multi-core support to OpenVPN I would start with the Apache httpd 1.3 or 2.x code base (1.3 is simpler as it does not include apache's MPM stuff). Httpd + mod_ssl has already solved the issue of accepting multiple client connections and should/will have similar issues with key renegotation. I would also opt for function handlers/pointers per connection - that way you could server both udp+tcp from a single server instance - the client connection entry element would then contain pointers to the right handlers for tcp, udp and possibly even tun or tap. JM2CW, JJK >> 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. > ------------------------------------------------------------------------------ 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
