David Schwartz wrote:
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!
My initial negotiation has taken place completely, I am using
SSL_accept() as many times as it needs to complete that phase before
moving on to do any SSL_read() or SSL_write().
Sorry I should have been clearer, I was requesting what specific
scenarios can cause it. Maybe there is only the "re-negotiate" one ?
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.
But I think you miss my point I am making in this paragraph
I am asking if I never call SSL_read(), is it possible for my
SSL_write() to return WANT_READ ? i.e. if I am no longer taking new SSL
data from my peer, I can no longer be receiving requests to
re-negotiate. And if re-negotiation is the only cause of WANT_READ from
SSL_write() then I think my problem scenario is pretty much solved.
What concerned me was I don't actually want to read any data while I am
bulk writing data, hence SSL_peek(). But if I'm not reading data full
stop I dont have a problem. And if I am reading data thats okay because
my application can deal with new data (or re-negotiation) requests at
that time. Because I read new data inbetween the bulk writes.
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 dont mind that so much. That is I wouldn't have a big problem setting
up the input buffer for SSL_write() to be static and a unique allocation
per (SSL *), since I am already copying to data onto the stack before I
issue an SSL_write(). So using BIO for input is fine.
When you talk of BIO *pair*, is the pair for read/write or the pair for
input (plain text) and output (cypher) ?
From what you've said I think I shall investigate that some more, after
I am happy with the basic design. If I can do away with the copying
data to stack when I use SSL_read()/SSL_write() and get SSL to put it
direct that will save 2 copies per round trip.
Thanks for your response,
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
