> > There may not be any application data, but there should
> > be data sent over the SSL connection.
> Protocol data? Like an ack for some previous data sent?
Well, remember no data at all can be sent until a key is negotiated. So
if
you immediately call SSL_write, it will be unable to do anything.
> > If either an SSL_write or an SSL_read results in a
> > WANT_READ error, it means that neither call can progress
> > until some data is read from the socket. You can retry the
> > operation later, try another operation, or whatever you want
> > to do. You can take the hint that 'select'ing on the socket
> > for readability will likely tell you when the operation is
> > going to succeed.
> I do select on the socket. Basically, I have a thread pool that I use for
> I/O. Writes are synchronous, so I expect to finish writing all the data
> before I exit my write function. But since I don't want to tie
> up a thread
> blocking on the read waiting for data to arrive (since I have no idea when
> data will arrive), I add it to a list of sockets that I am select'ing on.
> Since my write is synchronous, and if I get a WANT_READ error, then that
> means I need to read some ssl data before I can continue. So I
> will select
> on the socket until data arrives. I'm assuming that the data WILL arrive.
> There is no chance that I could be blocked here indefinitely is
> there? I'm
> assuming that the data is some SSL protocol data that is SHOULD have been
> sent by the other end of the connection (assuming it is a valid
> SSL client).
You can impose timeouts if you want. You have this same issue for TCP.
If
the other side doesn't read any data, eventually your 'write' will block
forever. You have to handle this yourself.
> Now, I also have a read thread that was select'ing on the socket
> waiting for
> data to arrive. So either of these 2 threads may read data. Both threads
> are select'ing on the socket. So if the read thread wakes up first and
> acquires the lock, then it will do an SSL_read before the write
> thread wakes
> up and retries an SSL_write (which was the operation that caused the
> WANT_READ error in the first place). So my question is, is this
> ok?
Yes. Just understand that it's not unusual to see data on the socket
(in a
call to 'select') and then not get any *application* data from SSL_read.
> If it
> was an SSL_write that caused the WANT_READ error, do I HAVE to retry the
> SSL_write before I can do an SSL_read?
No. You will likely need to enable SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER
and
will probably want to enable SSL_MODE_ENABLE_PARTIAL_WRITE as well. Read up
on these and make sure you understand the implications and especially the
very unusual default of net accepting moving write buffers!
> The SSL_read should read whatever
> data the ssl state machine was expecting, and the next try of SSL_write
> should then succeed right?
Yes. Just remember that there are two weird cases that could happen --
expect them.
1) You get a read hit from 'select', but before you can call SSL_read,
your
write thread calls SSL_write, which reads the data. So now when you call
SSL_read, nothing at all happens.
2) You get a read hit from 'select', but it's all protocol data, no
application data. So you call SSL_read and no application data is returned.
And, of course, remember that you need a mutex for the connection to
prevent a concurrent SSL_read and SSL_write.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
