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 <[email protected]> > To: [email protected] > Subject: Re: curl_easy_perform connection termination scenario > Message-ID: <[email protected]> > 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
