Platform is linux 2.6.18
curl is 7.15.4

Server is breaking connection every minute one to three times (no
particular pattern timing wise)
Is there any way to tell curl to make only connection (not issue http
GET) with server if connection is broken?

I dont think preemption is happening for so long time - otherwise I
would have noticed it if it had happened somewhere else other than
curl api.

Request was made at around 11:01:12.302
curl_easy_perform returned at 11:01:13.184

11:01:13.184617 errcode: 200
11:01:13.184636 totaltime: 881.819000
11:01:13.184651 connecttime: 653.956000
11:01:13.184670 avgdnldspeed: 965.000000
11:01:13.184686 size : 851.000000
11:01:13.184698 filetime(sec): -1
11:01:13.184715 namelookuptime: 649.325000
11:01:13.184735 pre_xfer_time: 771.337000
11:01:13.184752 start_xfer_tim: 881.801000
11:01:13.184767 redirect_time: 0.000000
11:01:13.184774 redirect_count: 0

Curl is claiming connection time 653 ms, n/w trace does not support that.

following is firewall trace (Note there is time offset between host & firewall)

2277 11:01:13.171 203.243.24.23 172.206.36.76 TCP
57482 > https [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1
TSV=313672783 TSER=0 WS=7
2278 11:01:13.171 203.243.24.23 172.206.36.76 TCP
57482 > https [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1
TSV=313672783 TSER=0 WS=7
2279 11:01:13.175 172.206.36.76 203.243.24.23 TCP
https > 57482 [SYN, ACK] Seq=0 Ack=1 Win=4380 Len=0 MSS=1460 WS=0
SACK_PERM=1
2280 11:01:13.175 172.206.36.76 203.243.24.23 TCP
https > 57482 [SYN, ACK] Seq=0 Ack=1 Win=4380 Len=0 MSS=1460 WS=0
SACK_PERM=1
2281 11:01:13.175 203.243.24.23 172.206.36.76 TCP
57482 > https [ACK] Seq=1 Ack=1 Win=5888 Len=0
2282 11:01:13.175 203.243.24.23 172.206.36.76 TCP
[TCP Dup ACK 2281#1] 57482 > https [ACK] Seq=1 Ack=1 Win=5888 Len=0
2283 11:01:13.186 203.243.24.23 172.206.36.76 TLSv1
Client Hello
2284 11:01:13.186 203.243.24.23 172.206.36.76 TLSv1
[TCP Out-Of-Order] Client Hello
2285 11:01:13.192 172.206.36.76 203.243.24.23 TLSv1
Server Hello
2286 11:01:13.192 172.206.36.76 203.243.24.23 TLSv1
[TCP Out-Of-Order] Server Hello
2287 11:01:13.193 203.243.24.23 172.206.36.76 TCP
57482 > https [ACK] Seq=122 Ack=80 Win=5888 Len=0
2288 11:01:13.193 203.243.24.23 172.206.36.76 TCP
[TCP Dup ACK 2287#1] 57482 > https [ACK] Seq=122 Ack=80 Win=5888 Len=0
2289 11:01:13.292 172.206.36.76 203.243.24.23 TLSv1
Change Cipher Spec, Encrypted Handshake Message
2290 11:01:13.292 172.206.36.76 203.243.24.23 TLSv1
[TCP Out-Of-Order] Change Cipher Spec, Encrypted Handshake Message
2291 11:01:13.292 203.243.24.23 172.206.36.76 TCP
57482 > https [ACK] Seq=122 Ack=131 Win=5888 Len=0
2292 11:01:13.293 203.243.24.23 172.206.36.76 TLSv1
Change Cipher Spec, Encrypted Handshake Message
2293 11:01:13.293 203.243.24.23 172.206.36.76 TCP
57482 > https [ACK] Seq=122 Ack=131 Win=5888 Len=0
2294 11:01:13.293 203.243.24.23 172.206.36.76 TLSv1
[TCP Out-Of-Order] Change Cipher Spec, Encrypted Handshake Message
2295 11:01:13.396 172.206.36.76 203.243.24.23 TCP
https > 57482 [ACK] Seq=131 Ack=173 Win=4552 Len=0
2296 11:01:13.396 172.206.36.76 203.243.24.23 TCP
[TCP Dup ACK 2295#1] https > 57482 [ACK] Seq=131 Ack=173 Win=4552
Len=0
2297 11:01:13.396 203.243.24.23 172.206.36.76 TLSv1
Application Data
2298 11:01:13.396 203.243.24.23 172.206.36.76 TLSv1
[TCP Out-Of-Order] Application Data
2299 11:01:13.403 172.206.36.76 203.243.24.23 TLSv1
Application Data
2300 11:01:13.403 172.206.36.76 203.243.24.23 TLSv1
[TCP Out-Of-Order] Application Data
2301 11:01:13.443 203.243.24.23 172.206.36.76 TCP
57482 > https [ACK] Seq=394 Ack=1192 Win=8064 Len=0
2302 11:01:13.443 203.243.24.23 172.206.36.76 TCP
[TCP Dup ACK 2301#1] 57482 > https [ACK] Seq=394 Ack=1192 Win=8064
Len=0

> Message: 5
> Date: Thu, 10 Mar 2011 17:59:33 -0800
> From: Dan Fandrich <dan_at_coneharvesters.com>
> To: curl-library_at_cool.haxx.se
> Subject: Re: curl_easy_perform connection termination scenario
> Message-ID: <20110311015932.GB19995_at_coneharvesters.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Mar 10, 2011 at 06:56:06PM -0500, Pankaj Takawale wrote:
>> I noticed following behaviour of curl_easy_perform when server
>> terminates connection after sending response to curl client.
>>
>> Case1: curl_easy_perform returns immediately, and detects broken
>> connection at the time of next request.
>>       It then re-establishes the connection and retrieve page successfully.
>> Whole process takes around 220ms (200ms for TCP connection + SSL
>> Handshake, 8 ms for http response)
>>
>> Case2: curl_easy_perform is taking around 900ms to sec to return.
>>       In this case too, I see server returned response followed by TCP FIN
>> immediately.
>>       All termination packet flow is same as of case1.
>>       Still curl_easy_perform is taking 800ms further to return.
>>
>> Please advice any work around to deal with this.
>
> What platform and libcurl version are you using?  The TCP logs don't
> show any 900 msec delays, so it would be useful to see an instrumented
> libcurl log for the delay case. How often does the delay case happen?
> How do you know it isn't simply due to other higher-priority processes
> on the system preempting the libcurl-using process for that extra time?
>
>>>> Dan

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-03-11