1 Topic by da

  • da
  • Member
  • Offline
  • Registered: 2024-05-31
  • Posts: 2

Topic: low latency single threaded app

i have a c++ single-threaded app that uses wolfssl c library for the tls
the app receives data on existing connections and constantly closes and creates new connections
i have benchmarked the app and noticed that the 

wolfSSL_connect

function takes about 400 microseconds (btw i have setup the library to not check certificates), which means my messages get delayed by up to 400 microseconds, i create a lot of new connections which means a lot of spikes
i have lightly gone over the code in wolfssl and i have seen a lot of situations where there is a switch with cases like:

TLS_ASYNC_BEGIN
TLS_ASYNC_BUILD
TLS_ASYNC_DO
TLS_ASYNC_VERIFY
TLS_ASYNC_FINALIZE

between them there is 

FALL_THROUGH;

what i want is to remove the fallthrough or to return so that the wolfssl function is basically broken into multiple pieces, which might only cause 50 microseconds (or even less)
i would then have to call it more times and it obviously take longer to create a new connection, but i don't care because it would not impact the latency of the messages of my existing connection
---
it seems like a big undertaking though, and i would like some help/advice
is there an easy solution for what i want that i am just not seeing?
if not:
is there some documentation specifically for this case?
what are the things that i should watch out for?
is there some specific approach that i should take?
thank you in advance

Share

  • Registered: 2015-10-07
  • Posts: 430

Re: low latency single threaded app

Hi Daniel,

Your use case sounds very interesting and is one we do support. The handshake operations taking the most time are the cryptographic ones for asymmetric operations like shared secret and sign/verify. If you are using an ECC only cipher suite like ECDHE-ECDSA then you can enable our non-blocking crypto with TLS and break operations into much smaller chunks.

When the non-blocking build option is enabled the crypto calls will return WC_PENDING_E and you would just call the wolfSSL_connect/wolfSSL_accept API's again until complete.

This does require our asynchronous code from https://github.com/wolfssl/wolfAsyncCrypt.

We posted a nice blog on it here: https://www.wolfssl.com/wolfssl-bare-me … yptography

This use case is supported and used by many customers. However it might be useful to setup a call to walk you through it and hear about your use case. We will be emailing you directly to reach out.

Thanks,
David Garske, wolfSSL

Share