In the clinet, I use "netstat -an" and found the tcp connection is still
established.

2010/7/14 Dan Fandrich <dan_at_coneharvesters.com>

> On Wed, Jul 14, 2010 at 02:26:55PM +0800, ±¦Öì wrote:
> > When interface comes back, it will always use the previous address. But
> the
> > transfer does not resume more than one day.(One day is my longest test
> period).
> >
> > I have used the CONNECTTIMEOUT and FTP_RESPONSE_TIMEOUT option.
>
> I don't know why it would fail in this case, unless the server gets some
> kind of indication that the network link on the client went down and
> terminates the TCP connection without the client noticing. You could
> also try installing a CURLOPT_SOCKOPTFUNCTION and enabling TCP keepalive on
> the socket, like the curl --keepalive-time option does.
>
> >>> Dan
>
> >
> >
> > 2010/7/14 Dan Fandrich <dan_at_coneharvesters.com>
> >
> > On Wed, Jul 14, 2010 at 11:43:58AM +0800, ±¦Öì wrote:
> > > I am using curl-7.18.2-6.fc10(libcurl.so.4.1.0) in linux
> > > 2.6.21.7-hrt1-WR2.0ap_standard #1 PREEMPT.
> > >
> > > I invoked a get file transfer job, before it completes the download
> job,
> > there
> > > is a network interface down event, but this only last several
> seconds.
> > > After the network interface being up again, the download job can
> not
> > > continue, even no exception happens when the network interface is
> down.
> > >
> > > The download job just hangs there and block my other process.
> > >
> > > Is it a well-konw problem? Is it already fixed? Have you recognized
> it?
> > >
> > > Do you know how to make a workaround for that or how fix?
> >
> > If the network interface comes back up with a new address, then the
> > existing
> > connection will no longer be able to continue and it will eventually
> time
> > out (which could take 20 minutes). If the interface comes back with
> the
> > same
> > address as before, the transfer ought to resume within a few seconds
> or at
> > most a few minutes. You can use the CURLOPT_LOW_SPEED_LIMIT and
> > CURLOPT_LOW_SPEED_TIME options to force an abort more quickly than
> TCP
> > would
> > normally do it, and/or just retry the transfer (an equivalent to the
> curl
> > tool's --retry option) to redo the transfer once it fails.
> >
> > >>> Dan
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-07-14