curl-library
Re: Problem with reusing persistent connections
Date: Thu, 13 Sep 2007 22:30:11 +0200
Dan Fandrich wrote:
> On Thu, Sep 13, 2007 at 09:45:10PM +0200, Stefan Krause wrote:
>
>> Normally I do more than one transfer between the physical connection goes
>> down (due to segmented transfers). As always HTTPS is used I get a big
>> overhead with the SSL handshakes when CURLOPT_FORBID_REUSE is used.
>> Calling curl_easy_cleanup() seems to be the only function which closes the
>> socket connections on demand, I found nothing similar. That call will also
>> delete all the other options and data associated with the handle.
>> Unfortunately I need this information for continuing the segmented HTTP
>> transfer.
>>
>
> Sounds like you want a curl_easy_close() or something to only close any
> sockets reserved by that easy handle but leave everything else unchanged.
>
>
Yes, exactly. Can that be proposed as a new feature? Do you know how
difficult that would be to implement?
>> So one solution might be the following: After the physical
>> connection has been reestablished, the configurations (urls, proxy
>> settings, etc.) of each easy_handle are saved. Then all easy handles are
>> cleared and new handles are created and configured with the saved
>> configuration. Then I have got identical configured easy handles as before
>> and none of them with an open connection. Running them would led to the
>> creation of new socket connections and SSL handshaked an the transfer can
>> continued immediately without waiting for the socket connection timeout to
>> expire. The SSL handshake is no overhead here, as it has to be done again
>> nonetheless. This reestablishment procedure won't happen two often, so it
>> should be ok. What do you think? Did I miss something important?
>>
>
> That sounds effectively the same thing--after restoring the handle state,
> the only thing that's different is that the sockets are closed.
>
Yes. That would be a workaround for your suggestion of the
curl_easy_close().
>
>>> There's no reliable way for libcurl to tell if the "physical connection"
>>> has
>>> gone down. In the Mobile IP case, even that wouldn't be grounds enough
>>> to close the sockets.
>>>
>>>
>> I did not understand that correctly. May you be so kind to explain it a
>> little more?
>>
>
> In the Mobile IP case, you can maintain a connection using the Mobile IP
> address even when the physical layer has been pulled out from under you.
> When the physical layer returns (it can be a different physical layer with
> a different IP address), the Mobile IP connection continues as though
> nothing happened. It's designed for exactly your kind of situation, and is
> included as part of 3GPP2's cdma2000 specifications, so CDMA cellphones
> already have it.
>
>
Thanks for explaining in more detail, now its understood.
>>>> Dan
>>>>
Received on 2007-09-13