> > I'm probably missing something, but what's wrong with select()'ing for > > read when your SSL_write returns WANT_READ? > > See relatively elegant read_write() implementation from > > http://www.rtfm.com/openssl-examples/ > > Nothing, but how do I know when I can start my SSL_write() again, > because the WANT_READ condition that is stopping SSL_write() from taking > any more data has cleared ?
Did you look at the code in openssl-examples? You call SSL_write It returns WANT_READ You stop select'ing for write on that descriptor and only select for read. Every time select tells you that the socket is readable you try calling SSL_write again. It will either succeed or it will return WANT_READ again, in which case you keep waiting for more data... and then call SSL_write again. > After every SSL_peek()/SSL_read() do I try to issue a new SSL_write() > and if there is movement I consider it cleared ? You don't need SSL_peak/SSL_read. SSL_write will do the reading that it wants to do. > The problem here is how to detect when I can drive my SSL_write() by the > writable event select() indicator and when I have to disregard it (even > though my application has Mb's of data still to send) until I know the > WANT_READ for SSL_write() condition has cleared itself. The way to clear WANT_READ for SSL_write() is to call SSL_write again, not SSL_read. Don't call SSL_read() if you want to write. > Then I can go > back to select() driven SSL_write()'s. The start disregard part I > understand. The switch back part I do not. It might take a couple of attempts I guess if not all data arrives at once, but it's not a problem. You'll be blocked in select and servicing other fds in the mean time (if there are other fds of course). > Ideally I don't want to use SSL_read() to take application data from > OpenSSL at that moment (because the application doesn't want it at that > time), I ideally want to be using SSL_peek() to give OpenSSL program > control to service read() and clear condition. You don't need either. All you need is calls to SSL_write. > But having thought about that situation some more what if I have too > much data in my inbound buffer waiting for the application then OpenSSL > may not call read() because its buffers are full enough already to > service my SSL_peek(). But I dont know exactly how its internal > buffering works to be sure, maybe it will just eat more memory ? > > So I guess I must service it with SSL_read() enough to allow the other > end and the respective flow controls to pull enough data through to get > to the packet thats currently holding up my SSL_write() ? I guess it will keep growing the buffer until it gets the stuff that it wants... Are you saying that you are receiving a lot of data and not looking at it? That can in fact cause problems, I guess. But why are you not reading it? I'm not 100% sure that there is a way to handle the situation where you keep ignoring the incoming data and leave it in OpenSSL's buffer. You might end up with a growing memory utilization of in fact get stuck because SSL_write can't read the data it needs because the buffer is full. It contradicts the documentation though: ***** As at any time a re-negotiation is possible, a call to SSL_write() can also cause read operations! The calling process then must repeat the call after taking appropriate action to satisfy the needs of SSL_write(). The action depends on the underlying BIO. When using a non-blocking socket, nothing is to be done, but select() can be used to check for the required condition. ***** I do beleive that the only time SSL_write will return WANT_READ is if a renegotiation is happening. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
