First of all, I want to thank everyone for all the information, especially David with his excellent explanations. I know this thread is getting long, but I really think I'm getting it now :) Just a few more questions and comments...
> > > 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. Of course :) > > > > 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. Of course. But what I mean is, if I get a WANT_READ from an SSL_write, than I assume that means I am waiting for some protocol data to satisfy the ssl state machine, right? After all, SSL_write should not be waiting for any application data. So if that is the case, does that mean that the protocol data that I am waiting for SHOULD have been sent by the other end of the connection? > > > 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. Will SSL_read return 0 bytes read, or will I get a WANT_READ error indicating there was nothing to be read since the data was already read off the socket? > > 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. Does SSL_read always return the number of bytes of application data read? If so, that means that SSL_read could return 0, and that this should not be construed as an error. > > And, of course, remember that you need a mutex for the > connection to prevent a concurrent SSL_read and SSL_write. Of course. That was my first mistake. But I know better now :) > > DS > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
