You're right -- the latter.
Another thing to think about is that at any time, the remote peer might request a re-negotiation. During such time, the session key will be re-established requiring a few round-trips during the DH process. This will all be handled behind the scenes as you attempt to move application data through the system. If the SSL state machine is waiting on some remote data to be received during the re-negotiation, you will get a WANT_READ in response to an SSL_write (or an SSL_read). At this point, you could call select() waiting for data to arrive. When select() indicates that the socket has data ready, you can just call SSL_write (or SSL_read) again so that the state machine can work its way through the protocol.
In my program's case, I had to periodically call SSL_read() on a non-blocking socket so that I could detect whenever the remote peer closed the connection, even though I was not expecting any application data to arrive.
On Apr 17, 2005, at 10:20 PM, Edward Chan wrote:
Right, but let's say I'm doing an SSL_write, and I get a WANT_READ error. I
then select on the socket until data is available for reading. I then call
SSL_read. If all that was sent was the protocol data that the write was
waiting for to satisfy the ssl state machine, and no application data was
sent, would SSL_read return the number of bytes actually read off the socket
(which is just protocol data), or would it read that transparently and
return 0 indicating that no application data was read? Or would it just
read the required protocol data and return an error of WANT_READ to indicate
that I should retry the SSL_read when more data arrives? Now that I think
about it, I'm guessing the latter.
smime.p7s
Description: S/MIME cryptographic signature
