Hi David,
On 05-01-18 20:48, David Sommerseth wrote:
> On 04/01/18 13:07, Steffan Karger wrote:
>> If control channel packets arrive quickly after each other, or out of
>> order, there might be more data available than we can read in one
>> tls_process() call. If that happened, and no further control channel
>> packet arrived (e.g. because the last two packets arrived out-of-order),
>> we would wait for 16 second ("coarse timer") before we would read the
>> remaining data. To avoid that, always schedule ourself again if there
>> was control channel data, to check whether more data is available.
>>
>> For mbedtls, we could implement a slightly more elegant "is there more
>> data?" function, instead of blindly rescheduling. But I can't find a way
>> to implement that for OpenSSL, and the current solution is very simple and
>> still has quite low overhead.
>
> I haven't looked at the code paths yet (except of the patch itself) ... but
> how will this affect a server config with a bit of load? Like some hundred
> connected clients or more? Will these other clients notice that a client gets
> rescheduled instantly? And as well, what if more clients trigger this
> behaviour approximately in the same time window?
Good question. One extra tls_process() loop for each connecting client
should have barely any effect. Based on the code, I would expect it to
be less processing than a single data channel packet. For more
certainty, I ran some tests.This is the average time for setting up 50 connections simultaneously without bandwidth limits or packet loss (om my 5-year old dual core laptop), and waiting for all 50 to finish (average over 20 runs): Without the patch: Mean: 11.16 Stdev: 0.35 With the patch: Mean: 11.14 Stdev: 0.36 Same test, but now with an iperf maxing out the data channel at the same time (laptop turns into a blowdryer...): Without the patch: Mean: 11.17 Stdev: 0.68 With the patch: Mean: 11.33 Stdev: 0.55 (iperf reported for both a little over 400 Mbit/s) I think these numbers are a strong indication that my 'barely any effect' estimate is correct. -Steffan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-devel
