|
|
> I'd expect he'd probably be okay with a beefy enough server once > OpenVPN's multithreading support is back in place -- particularly if he > boosts the key renegotiation interval, or (even better) has a > client-connect script adding some random fuzz to the renegotiation > interval (so as to stagger renegotiations even if all the clients > initially connect at the same time). There's already a certain amount of built-in fuzz in the scheduling algorithm to prevent too many tasks stacking up in the same time slice. > There still might be some trouble as everyone reconnects after downtime > or a like event, but my guess is that it'd be workable. Be useful to > know a bit more about what he's trying to do (and thus how critical it > is for clients to reconnect promptly following downtime) to offer more > suggestions -- but one could conceive of having the client instances > configured to exit when disconnected from the server and running in a > supervised scripting loop that places a random amount of delay before > restarting the client instance; this would help to avoid the > everyone-pile-on-the-server effect. > > James, what's the status of multithreading support? I'm hoping to get pthread support back in for 2.1. Having said that, I don't think it's going to make much of a difference in most cases. Where it will matter is if you have scripts which take more than 100 milliseconds to execute. James ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |