In the clinet, I use "netstat -an" and found the tcp connection is still established.
2010/7/14 Dan Fandrich <[email protected]> > 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 <[email protected]> > > > > 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
