cURL
Haxx ad
libcurl

curl's project page on SourceForge.net

Sponsors:
Haxx

cURL > Mailing List > Monthly Index > Single Mail

curl-library Mailing List Archives

Re: connect-timeout not working

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Fri, 4 Jan 2002 16:50:44 +0100 (MET)

On Fri, 4 Jan 2002, Georg Horn wrote:

[Warning, this is big-time libcurl development talk! ;-) I've cc'ed this to
the libcurl list and we should probably continue this thread over there...]

> > Using signals is not a good solution. Using non-blocking sockets might be
> > better, as then OpenSSL shouldn't be able to hang either.
>
> Yes, that could be a solution. I'll try to play around with this a little
> bit...

I grabbed my "SSL and TLS" book (ISBN 0201615983) to figure out some more
details on this, and this only confirms what's been said already.

When select() returns that there is data to be read from SSL, we eventually
call SSL_read() to get the data. But the select() call only knows about
network buffers, not SSL records, and SSL apparantly operates on records (it
has to get a full record before it can deliver even a single byte). So if
only a fraction of an SSL record arrives, select() will return saying there
is data to read and when we call SSL_read(), it'll hang there until it has
read the rest of the record.

That is not nice.

We no longer have any means to cancel such a "hang". We must use non-blocking
sockets to prevent this from happening.

For the same reason as given above, select() can't always know when there is
data to read from SSL:

Consider the case where we SSL_read() 100 bytes successfully. We get 100
bytes into our buffer, but we have no idea how many more bytes the SSL layer
may have had to read from the network to get these 100 for us. If we go back
to the select() loop to wait for more input from the network, it can very
well just hang there waiting for network level data while the SSL layer has
more data for us already...

Thus, after having read one chunk of data from SSL, we must ask it if it
still has data for us, using SSL_pending() and if so: loop. This is not done
today.

If I'm right, this is not to be confused with the return code
SSL_ERROR_WANT_READ that can be returned already today (and we have code to
deal with it), like for example when a renegotiation takes place. The OpenSSL
docs for SSL_read[1] also mentions that it can in fact also return
SSL_ERROR_WANT_WRITE, as a negotiation may involve writing (this is not dealt
with in the current code).

[1] = http://www.openssl.org/docs/ssl/SSL_read.html

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/
Received on 2002-01-04

These mail archives are generated by hypermail.

donate! Page updated November 12, 2010.
web site info

File upload with ASP.NET