> Subject: Persistent connection problem
> Hi,
>
> I am using libcurl 7.10.7 on a redhat 7.2 machine within my C programs
> with the easy interface to process requests with an HTTPS server.
> Everything works well as long as I start a libcurl easy session with the
> curl_easy_init call before doing a request.
>
> However, I would like to use the keep-alive feature of HTTP/1.1 and
> thus, I have changed my software in order to perform a single
> curl_easy_init at program start (and a single cleanup at the end). In
> this sitution, I see strange things when looking at the packets with
> tcpdump.

Hi Andreas,
while talking about persistent connection, can you really see the libcurl
keeps using the "same" connection ( same <port,ip> ) before 15 sec timeout?
If yes, could you briefly tell me how you configure the server and client
header ( Keep-Alive? etc...)
Sadly, I can't see libcurl uses the persistent connection ~~

> cURL establishes a new connection with the SSL server, performs the SSL
> handshake and then sends the request and receives the answer (in fact,
> one can only see that packets are sent since everything is encrypted,
> but my application works). As they should, neither cURL nor apache send
> F (fin) or R (reset) packets. Since apache is (by default) configured to
> kill persistent connections after 15 seconds, an F packet is sent by
> apache after that time (and curl sends an ack for that). So far, so
> good.
>
> However, curl seems not to recognize that the connection is gone. When a
> new request is started, cURL tries to use the old connection which it
> has acknowledged to be finished a few seconds before. As apache sends a
> reset for that immediately, cURL starts a new connection and performs
> the requst without further problems.
>
> You might think that this bug does not matter because the only problem
> is that two more packets are exchanged, but this is not true. Imagine a
> firewall with stateful inspection between cURL and apache, and you will
> see that after the F packet from apache (and the ack for that) no more
> data will be accepted on that connection (since it is in fact closed).

what do you mean by "no more data will be accepted"?
you mean the firewall would block the data ( from client to server ) which
tries to use "has been closed" connection?

> Thus, cURL will try to reuse the connection and wait until a timeout
> occurs, and this takes much time.

It seems like the server won't get that data, and won't have chance to send
reset to client.
The timeout here, as you mentioned, is set by firewall? The firewall would
help to send similar stuff like "reset" to client while timeout occurs?
I think how firewall handles it depends a bit on its implementation, or it
shall be standardized?

- Jerry

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2003-09-16