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? -- kind regards, David Sommerseth OpenVPN Inc
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
