> Yes, what I meant by "My application's main task in the moment is
> sending bulk data, a lot of data (enough to cause flow control
> bottleneck)." meant exactly what you are asking. A previous SSL_write()
> returns WANT_WRITE, which I presume is because the OpenSSL BIO_s_socket
> did a write() which returned EAGAIN, so I put the fd into a select()
> fd_set for write, waiting for the O/S to have room for more data.
That sounds completely right so far.
> My application is then woken because the O/S says I can now write. So I
> call SSL_write() again, but this time I get back WANT_READ.
Okay, so now you OpenSSL has to read some data before it can write.
> So now I can't drive my next SSL_write() from the O/S writable
> indication, because I'd end up in a tight loop, until the read data came
> in and I did a SSL_peek() to clear the WANT_WRITE, the next iteration of
> the tight loops would clear.
Correct. So you need to 'select' just for readability. You are now
blocked
until some protocol data is received.
This is a funny version of the same mistake as before. You want to send
application data, so you are selecting for writability. But the SSL protocol
requires you to send protocol data before any application data can be sent.
So again, you get incorrect results from 'select' that don't tell you what
you really wanted to know.
> Having thought about the issue some more, what scenarios can cause a
> WANT_READ for SSL_write() call ?
If the SSL protocol requires the server to get some information before
it
can send any information. For example, if it's still doing the original
negotiation, it can't send any application data because it doesn't know the
key yet!
> If my application is not reading from
> the socket (even when data maybe there) because its busy doing
> SSL_write() then is it possible for a WANT_READ to occur ? Does the
> other end have to send something (renegotiation request) in order for
> setup that condition. Or do I have to instigate something for trigger
> the possibility of a WANT_READ for SSL_write() call ?
I'm not sure whether you need to call SSL_read before you select, but it
couldn't hurt and could help, though it may be unnecessary cost. I think the
right thing to do is to stop selecting for writability and select for
readability. When you make some forward progress on the reading front, you
may try the writing again.
> I dont like the idea of BIO pair, as the data from some places is
> already tripple buffered in my app. I'm sure SSL adds double buffering
> too (to transform the encryption).
Actually, it has a very cool way to minimize the copies, though I'm not
sure if it works out to be cheaper or more expensive when everything is
considered. When you do, say, a read, rather than giving a buffer for
OpenSSL to copy into, you give it a pointer and it puts a pointer to where
the data already was in there. Look at BIO_nread.
> I would like OpenSSL to be an efficient approach and elegant solution
> but the more I look the less happy I'm becoming.
I find bio pairs elegant, but your point is well taken.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
