> 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 ?
You are wrong in theory. Any SSL operation can churn the SSL state machine and decrypt data. SSL_read is not the only one. > > 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. Why would you do that? You never got a WANT_WRITE indication. > 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 ? Or the next SSL_read might, and the next SSL_write will just tell you it finished. Any SSL operation can run the SSL state machine. > > 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 ? There was never a WANT_WRITE indication. Setting the write mask would be an error. Here's the example again: 1) You call SSL_write to send the critical data. But a negotiation is not complete, so it returns 'WANT_READ'. You make a note to 'select' before writing. 2) You call SSL_read just in case the other side sent anything. It reads the negotiation data but no application data. It returns 'WANT_READ'. 3) You now call 'select' to wait before *writing*, and wait for the negotitation data to arrive even though it already has. Notice, there are no 'WANT_WRITE' indications here. So the socket should *NOT* be in the write set. > > 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. You don't have anything to write on the TCP connection. Why do you think you have something to write ON THE TCP CONNECTION? You only want to write on the SSL connection, and the SSL connection has not returned a 'WANT_WRITE' indication. You are still confused. > 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 That won't help. The timer will timeout the 'select', but you won't get a hit on the socket, since it's not ready to read. So you won't call SSL_write if you are still acting on the, now incorrect, WANT_READ indication. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
