Hi,
I am trying to implement bufferization of data on a SSL connection
at the application layer. To do so I implemented a wrapper to SSL_write,
which fills a buffer rather than sending data directly to SSL_write.
When the buffer is full the data is flushed in a call to SSL_write, but
when the buffer is not full I still want to ensure that the buffer will
be flushed eventually.
I have a difficulty in doing so, the thread buffering the data is
also the one calling SSL_read on the socket, I would like to prevent it
from being frozen if the call to SSL_read does not return (I think the
problem will be the same if two threads were doing SSL_write / SSL_read,
since I must ensure the SSL* is not used simultaneously)/
From what I could understand, if the BIO under SSL_read is non
blocking I am sure that SSL_read will return even if no data is
available (with a SSL_ERROR_WANT_READ error code) but the problem is
that I am not able to distinguish this error code from a possible
renegociation (which also returns SSL_ERROR_WANT_READ). While the
renegociation requires me to call SSL_read again with the same
parameters, a SSL_ERROR_WANT_READ allows me to flush my write buffer in
a SSL_write call, is not it ?
Thus my questions:
1. how can I distinguish a data famine from a renegociation occuring on
my SSL connection ?
1.2 In the case of a data famine, can I be sure SSL_read will return
"rapidly" (not block) if there is no complete data record to be processed ?
2. Using BIO_f_buffer, it seems there is a way to request OpenSSL to
buffer write data up until max Record size (setting buffer size from 4
to 16KB), is there a "OpenSSL way" to ensure the BIO_f_buffer will be
flushed periodically or must it be implemented externally ?
best regards,
Nicolas Brunie
