Hi Jerry,

cURL in fact supports persistent connections without any additional
configurations, I use an apache web server on the other side and perform
several requests with the same curl handle.

If a firewall with stateful inspection is placed between curl and the
web server, a packet with a finish or connection reset will cause the
firewall to block all later packets on that connection. Thus, if cURL
tries to reuse a connection which has already been closed, the firewall
will block that and cURL will not even receive a connection reset for
that. Thus, it will take some time until cURL gets a timeout.

I hope this helps,

regards,

Andreas

Message: 7
From: "Jerry G. Chiuan" <jerry_at_oridus.com>
To: <curl-users_at_lists.sourceforge.net>
Subject: Re: Persistent connection problem
Date: Mon, 15 Sep 2003 17:42:34 -0700
Reply-To: curl-users_at_lists.sourceforge.net

> 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