i have a question regarding the .options.alertCount member of a wolfssl object:
when/where is this byte reset in the wolfssl object?
i can see where it is incremented, but i don't see when/where is it reset. i assume there is a memset somewhere, but i can't seem to find it.

i am getting the -427 error sometimes in a client app (so i don't care about dos attacks), and i am wondering if it makes sense to increase the limit to something big like 100 instead of the default 5, or would it still get tripped eventually (because it is not reset)?

thank you in advance for the help

hello

i have a c++ app that connects to another machine and (rarely) gets sigpipe, which is bad since i want the app to keep running and try again later
the stacktrace looks like this:
wolfSSL_write ->
SendData ->
SendBuffered.part.0 ->
EmbedSend ->
"../sysdeps/unix/sysv/linux/send.c", line 23, in __libc_send ->
"../sysdeps/unix/sysv/linux/send.c", line 28, in __libc_disable_asynccancel

i assume that the other machine disconnects between the app checking the validity of the connection and wolfSSL_write
obviously, i can make a signal handler that throws an exception on sigpipe and then catches the exception outside wolfSSL_write
but i am curious whether i can make a signal handler that ignores the sigpipe, and then just continue with the wolfSSL_write
i assume wolfSSL_write should return -1, and then i would get the exact error with wolfSSL_get_error

my questions are
1. did i understand correctly that on sigpipe while writing, although sigpipe is raised, wolfssl will return -1?
2. what is the error i would receive from wolfSSL_get_error in this case?

thank you

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