cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: make only connect, but not issue GET request

From: Pankaj Takawale <pankaj.takawale_at_gmail.com>
Date: Thu, 17 Mar 2011 00:39:11 -0400

> Message: 4
> Date: Tue, 15 Mar 2011 18:50:07 +0100 (CET)
> From: Daniel Stenberg <daniel_at_haxx.se>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: make only connect, but not issue GET request
> Message-ID: <alpine.DEB.2.00.1103151841370.22231_at_tvnag.unkk.fr>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Tue, 15 Mar 2011, Pankaj Takawale wrote:
>
> Please stop the top-posting.
>
>> I'm polling web server using curl. Network trace shows me that - web server
>> breaks the connection on prev hit after sending response. When I try to make
>> next request, curl_easy_perform detects broken connection, re-connects and
>> make transfer. Re-connection is expensive over here - around 300ms (TCP
>> connection + SSL handshake).
>>
>> I would like to detect broken connection and re-connect only (NO transfer)
>> well before I make next request. This would mostly save re-connection time
>> at the time of next request. Do you see any work-around to achieve same
>> effect?
>
> I can see how it could possibly help your case, but libcurl doesn't support
> just getting the connection up and put into the connection cache for
> (possible) later use. Of course you could achieve almost that by doing just a
> HEAD request on the site to get the connection back.
>
> Also, putting back the connection like that would only be a work-around that
> lowers the average re-connect time, it won't fix the worst case since you
> could still experience that the connection gets dropped immediately before you
> want to use the connection.
>
> I would suggest that you make sure to use a modern libcurl version and that
> you re-use the handle so that you get SSL session-id caching that will
> minimize the re-connect time needed.
>
> --
>
>  / daniel.haxx.se
>
>
> ------------------------------

I tried with latest libcurl. I turned on CURLOPT_SSL_SESSIONID_CACHE.
As per n/w trace, "Client Hello" & "Server Hello" session-id's are
same. Still client & server goes ahead with certificate verification &
key negotiation.

   3287 17:27:06.352 CLIENT SERVER TCP 48175 >
https [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSV=280371865
TSER=0 WS=7
   3288 17:27:06.355 SERVER CLIENT TCP https >
48175 [SYN, ACK] Seq=0 Ack=1 Win=4380 Len=0 MSS=1460 WS=0 SACK_PERM=1
   3289 17:27:06.355 CLIENT SERVER TCP 48175 >
https [ACK] Seq=1 Ack=1 Win=5888 Len=0
   3290 17:27:06.366 CLIENT SERVER TLSv1 Client Hello
   3291 17:27:06.369 SERVER CLIENT TLSv1 Server Hello
   3292 17:27:06.369 CLIENT SERVER TCP 48175 >
https [ACK] Seq=122 Ack=80 Win=5888 Len=0
   3293 17:27:06.469 SERVER CLIENT TLSv1 Change
Cipher Spec, Encrypted Handshake Message
   3294 17:27:06.469 CLIENT SERVER TCP 48175 >
https [ACK] Seq=122 Ack=131 Win=5888 Len=0
   3295 17:27:06.469 CLIENT SERVER TLSv1 Change
Cipher Spec, Encrypted Handshake Message
   3296 17:27:06.572 SERVER CLIENT TCP https >
48175 [ACK] Seq=131 Ack=173 Win=4552 Len=0
   3297 17:27:06.572 CLIENT SERVER TLSv1 Application Data
   3298 17:27:06.577 SERVER CLIENT TLSv1 Application Data

Client Hello Session ID:
00:00:09:95:d8:2e:98:5c:e7:01:7a:19:cc:d3:71:3c:d1:96:41:37:58:58:58:58:4d:81:29:89:00:00:24:d9
Server Hello SessonID :
00:00:09:95:d8:2e:98:5c:e7:01:7a:19:cc:d3:71:3c:d1:96:41:37:58:58:58:58:4d:81:29:89:00:00:24:d9

Am I missing here something?

I believe I can not use CURLOPT_CONNECT_ONLY since it doesn't put
connection into cache for further re-use?

Thanks.

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