Dan Fandrich wrote:
> On Tue, Sep 11, 2007 at 07:38:49PM +0200, Stefan Krause wrote:
>
>> Questions:
>> 1) According to my understanding I need a way to renew the connections from
>> my multi and/or the contained easy handles when the physical data
>> connection
>> of the mobile phone has been re-established? HTTP transfers are
>> segmented.
>> That means that the physical data connection can be shut down and
>> re-established during an ongoing transfer. The use case for that might be
>> a high prio voice call which needs the mobile phone, the HTTP transfer
>> will then be interrupted and continued after the data connection has been
>> re-established.
>>
>
> If you reestablish the data connection and you get a new IP address, then
> there's no way to "reuse" the existing connection and continue the HTTP
> transfer because the existing connection is lost and the transfer is aborted.
> You would need to run Mobile IP for this to work.
>
>
OK. As I almost always get a new IP address, the existing connection
won't be usable in most cases after the physical data connection has
been reestablished. Mobile IP is not available in the
application/system. HTTP transfers are done segmented by my application
(by usage of the Content-Range header, for up/downloads). It may happen
that 5 of 10 segments have been transmitted successfully. Then the
network connection breaks down (due to network loss in a tunnel for
example) and is established again. Now the network interface got a new
IP address and the curl handle which has been used has a socket
connection which cannot be used anymore. The application has to wait
until the timeout expires before it can continue transmitting data,
although everything is setup and ready for transmitting data
immediately. We are waiting on a connection which is most probably
death. That waiting depends on the timeout configured. Currently I use 2
minutes with CURLOPT_OPERATION_TIMEOUT. Using a too small timeout here
would result in a abort of normally perfect running transfers. But
waiting 2 minutes after a new network connection is also not very good,
because these 2 minutes have to be payed in case CSD is used by the phone.
>> 2) What is the right way to trigger renewal of the connections ?
>> a) Should the Client-App inform somehow libCurl to renew the connections?
>> How is that possible? OR
>>
>
> The CURLOPT_FORBID_REUSE should work well if you're only doing one transfer
> between the times when the physical connection goes down, otherwise, it
> does mean extra overhead. You can also call curl_easy_cleanup to
> close any existing connections on demand. Unfortunately, I don't believe
> libcurl currently will reuse an existing SSL context across connections.
>
>
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. 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?

Bye,

 Stefan

>> b) Should the closing of the physical data connection force the sockets
>> which
>> are currently in use by libCurl being closed. So that libCurl
>> establishes
>> a new connection?
>>
>
> 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?
Thank you!
>
>>>> Dan
>>>>
Received on 2007-09-13