Thank you David, thank you all for the clarification.
Combining 'select' with blocking operations almost never works right. This is
the most difficult conceivable situation and you should not willingly choose it
I've been a bit confused. All my sockets are in non blocking mode.
Actually what I meant was : when I start a SSL_read, it'll try to read
an entire record. But it's not a blocking operation: if TCP had already
received the data it will really do. If not, it'll return (with
SSL_WANT_READ ?) and the rest of the record will be read at the next
SSL_read, then it'll be decrypted etc., and finally given to the caller.
SSL_pending does not do what you think it does. You simply want to call
SSL_read when you want to read and SSL_write when you want to write. If those
operations fail, they will tell you to use 'select'.
Actually, I do that. And I think I understand what SSL_pending does : it
returns the number of decrypted bytes remaining in the SSL buffer.
Implied: at least 1 SSL_read has been done before ! Am I wrong ?
3) You now call 'select' to wait before *writing*, and wait for the
negotitation data to arrive even though it already has.
So, if the negotiation data has arrived, SSL_write should work now. And
if you set the bit corresponding to the TCP socket associated with your
SSL in the "write mask", select should return immediately with that bit
up in the same mask. Then you make a new SSL_write, which should now
work without WANT_READ. I guess it can return a WANT-WRITE if the TCP
window of the other site is not sufficient to write the entire record;
in that case the next SSL_write will finish the pending write. Won't it ?
At this point, we have deadlocked. We are in 'select' waiting for data to
arrive to complete the negotiation, but it already has. The application
programmer has forgotten that when 'SSL_read' returned 'WANT_READ' that
obsoleted the 'WANT_READ' indication from 'SSL_write'.
IMHO, there is no deadlock if the programmer set the corresponding bit
in the "write mask" before calling select. Did I miss something ?
An SSL connection has one application state. At step 3, the state is "need to read
some data from the socket in order to give application data". It is an error to
'select' before calling 'SSL_write' in that state.
Sorry, but I don't understand why it's an error, assumed that you select
not only for read, but also for write if you have something to write.
And also use the timer (last argument of the call to select) to get
select returning if there is still noting to be read and you didn't
select for write
Best regards,
--
Francis GASCHET / NUMLOG
http://www.numlog.fr
Tel.: +33 (0) 130 791 616
Fax.: +33 (0) 130 819 286
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
