cURL / Mailing Lists / curl-library / Single Mail

curl-library

TFTP transfer is not aborted by non-zero value returned by CURLOPT_PROGRESSFUNCTION

From: Marcin Adamski <mass85_at_tlen.pl>
Date: Mon, 26 Sep 2011 15:20:46 +0200

Hi everyone

My libcurl version is 7.21.5 and I have a problem in a following test case, when using multi interface.

After TFTP download is started, I drop connection with server by disconnecting Ethernet cable. In CURLOPT_PROGRESSFUNCTION I check the time of last change of NowDownloaded parameter value of this callback. If more than 5seconds elapsed since last change, I return 1 in this callback, because I assume that connection is dropped. This is a workaround for no support for CURLOPT_LOW_SPEED_TIME and CURLOPT_LOW_SPEED_LIMIT options in cURL's TFTP implementation.

The problem is that transfer is not finished immediately and CURLOPT_PROGRESSFUNCTION is called again and again until transfers actually ends after 1891.87 s. I added more debuggin to my program and after every single time callback functions returns 1, in CURLOPT_DEBUGFUNCTION I get message "Callback aborted". Just before transfer actually ends, debug function contains "Timeout waiting for block 504 ACK. Retries = 51" and later I receive message using curl_multi_info_read() with information that transfer has ended with code "Operation was aborted by an application callback". Moreover it seems that application is hung after that.
In my opinion it means that transfer has finished not because of abort by callback, but because that ACK had not been received.

I've googled that some person had similar problem in libcurl 7.21.6 with aborting smtp transfer in CURL_READFUNC_ABORT. That person found workaround by first storing and then in appropriate moment closing socket used by curl. Is there any better solution?

Thanks for any help.

Regards
Marcin Adamski

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