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.
Tim
--- Cory Albrecht <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I'm writing an IRC client to which I'm adding SSL to the DCC chat &
> send file functions. Everything went peachy keen with SSLing DCC chat,
> but I ran into a minor problem adding SSL to send file.
>
> Basically in DCC send file the sender sends 256 byte blocks of the file
> and the receiver acknowledges each block with 4 bytes of a long int
> saying total bytes of the file received so far. Originally the sender
> waited for each acknowledgement before sending the next block, but
> these days most IRC clients use the so-called "fast send" variant in
> which the sender doesn't wait for the acknowledgements.
>
> 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.
>
> I'm writing using VC++ on Win2Kpro with non-blocking sockets by way of
> the MFC class CAsyncSocket. When data is available on a socket
> CAsyncSocket::OnReceive() is called. My function then reads the socket
> until it is exhausted, the function exits and things go on until
> CAsyncSocket::OnReceive() is called again. My OpenSSL libs are
> openssl-0.9.7-stable-SNAP-20020831.
>
> I found it odd that everything would flow through just fine when
> writing blocks of 8192 bytes and smaller, but just one byte more would
> cause the SSL link to stall. And nor could I figure out why the error
> would be SSL_ERROR_WANT_WRITE. I made up a specific text file to test
> with - each line 64 bytes long (including the \r\n at the end) with
> number that increased every line so I could track how much data was
> actually getting through before the stall. The receiver gets every line
> in every block sent by the sender in all successful calls SSL_write(),
> sot it appears that as soon as SSL_write() returns -1 that not even
> part of the data is gets through. The sender also appears to receiver,
> with SSL_read() all the 4 byte acknowledgement blocks sent by the
> receiver.
>
> Is this an expected problem with SSL? I.e. it specifically can't handle
> writing blocks of larger than 8192 bytes at a time?
>
> Thanks in advance.
>
>
> __________________________________________________
> 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]
__________________________________________________
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]
