--- Xperex Tim <[EMAIL PROTECTED]> wrote: > Personally, I don't consider SSL_ERROR_WANT_WRITE to be an error. If > you are going to use > non-blocking sockets then you are going to have to expect that > sometimes the socket won't be ready > for writing. OpenSSL doen't want to busy-wait in that case so it > returns to you so you can do > something else while waiting for the socket to be ready. You can > have a thread block on select > call, for example.
I understand that, but my problem is nothing so simple as a sometimes the socket isn't ready problem. Like I said, I've verified that the receiving end has received all the data for which SSL_write() had returned successfully, so it's not merely a saturated output buffer on the socket that will drain when the network subsystem is given time to catch up. With buffer sizes of 8193 bytes or more, after SSL_write() returns an error it NEVER succedes ever again on that socket. My program does it's something else tasks, trying about every 0.1s to send more data with SSL_write(). But SSL_write() always returns -1 and SSL_get_error() always return SSL_ERROR_WANT_WRITE. I even let it continue over night once - 10 hours with no change. With a buffer size of 8192 bytes or less this problem NEVER happens. If this problem was just a non-blocking socket not being ready at that particular time of that one particular call to SSL_write(), you'd expect that during 10 hours of waiting the socket at some point would be come ready and more data could be sent. Or that such a transient socket not ready problem would happen occasionaly with the smaller block sizes, but it doesn't. According to the docs for SSL_write() that come with OpenSSL, when the error is SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, then "When using a non-blocking socket, nothing is to be done, but select() can be used to check for the required condition." So apparently I seem to be doing what I'm supposed to be doing, since CAsyncSocket in MFC converts select notices to a call of the proper OnReceive/OnSend/OnClose/etc... member function, an none of them are getting called after SSL_write() stalls like this. > --- Cory Albrecht <[EMAIL PROTECTED]> wrote: > > I enhanced my DCC send file code so that it could send blocks > larger > > than 256 bytes in order to speed up the process. This works fine > over > > an SSLed link up to 8192 byte block size. But at 8193 bytes and > higher > > per block the SSL_write() on the sender's side eventually ends up > > returning -1 every time with SSL_get_error() returning > > SSL_ERROR_WANT_WRITE, thus send file stalls. On the receiver's end > > SSL_write() never returns an error. SSL_read() doesn't return an > error > > on the receiver's side, either, but that's because I'm MSG_PEEK-ing > at > > the socket to see if there is data available. __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
