[openssl-users] Non-blocking SSL_read/SSL_write: difference between renegociation and data famine

[Nicolas Brunie]

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