> > Writing: > > > > 1) Acquire the mutex. > > > > 2) Call SSL_write. If we have sent all of the data, release the lock and > > returen. > > > > 3) If we sent any data, re-adjust to only send the data that remains and > > go > > to step 2. > > > > 4) If we got a zero, release the lock and return the number of bytes > > successfully sent. > > > > 5) If we got an error, pass the return value to SSL_get_error. > > > > 6) If the error is fatal error, release the lock and return. > > > > 7) Obey the WANT_READ or WANT_WRITE by releasing the lock, calling > > 'select', > > and re-acquiring the lock. Go back to step 2.
> I have looked into s_client example, and thought over your advice, but I > have one more doubt yet. > I think, the meaning of "ready for write" at select() is only > "there is some > space to write on TCP stack". Actually, the result of select() is almost > always "ready for write". Correct. > So, the meanings of WANT_READ and WANT_WRITE are really same as > buffer full > on TCP stack? WANT_READ means the SSL engine cannot make further progress until it can read some data from the socket. WANT_WRITE means the SSL engine cannot make further progress until it can write some data from the socket. > If not so, I think there is a possibility to cause non-wait > loop at step 2-7. There is one ugly situation, and I don't know a good way to stop it. Consider: 1) The receive buffer is empty, SSL_read returns WANT_READ. You release the lock and prepare to call 'select'. 2) Another thread acquires the lock and calls SSL_write. SSL_write calls 'read' and reads the data. SSL_pending would now return greater than zero. 3) You switch back to the first thread which blocks on 'select'. Unfortunately, the data it is waiting for has already arrived and been consumed. The only workarounds I know for this are horribly ugly. For example, you can call SSL_pending after every call to SSL_write, and if it's non-zero, you can write a byte to a pipe that the read thread also selects on. Maybe someone else knows a better way. I always use BIO pairs because I think OpenSSL's I/O code is not well thought out. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
