cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: TFTP and the Multi Interface

From: Chad Monroe <cmonroe_at_occamnetworks.com>
Date: Wed, 13 May 2009 16:34:39 -0700

On Feb 11, 2009, at 2:04 AM, Daniel Stenberg wrote:

> On Tue, 10 Feb 2009, Chad Monroe wrote:
>
>> I'm finishing up testing of my TFTP multi code but have one
>> question. When using the easy interface, tftp_disconnect() gets
>> called properly via close_connections() in Curl_close() which is
>> what curl_easy_cleanup() calls. In the case of the multi interface,
>> tftp_disconnect() never gets called, leading to a ~4Kb memory leak
>> on handle deletion.
>
> That sounds strange. When the multi interface is used, the
> connection cache is owned by the multi handle so thus
> tftp_disconnect() should be called when the connection cache is
> cleared, which should should happen when you call
> curl_multi_cleanup(). Unless the connection didn't fit in the cache
> due to size restraints, but then the connection should get
> disconnected immedately after the transfer was done.
>
>> Looking at curl_multi_cleanup(), it seems I need to add PROT_TFTP
>> to the PROT_CLOSEACTION mask in urldata.h. This solves my problem,
>> but is it the correct fix?
>
> No it isn't. That PROT_CLOSEACTION is meant for protocol actions
> necessary when a connection is to be disconnected, which so far FTP
> is the only one as it wants a "QUIT" command issued.
>
> Anyway, if you post your current work/patch perhaps we can help out
> better!
>
> --
>
> / daniel.haxx.se

Hi,

Sorry for the much delayed response. Here is the diff (I'm still based
on curl 7.19.2) between my modified source directory and the original.
Everything related to CURLOPT_TFTPBLKSIZE has been committed to CURL
CVS and is in curl 7.19.3, so it can be ignored. Other than the above
issue this multi code has been heavily tested on many of our embedded
platforms for TFTP RRQ (I have not tested WRQ yet). Once this issue is
resolved I'll run through all of the test cases and such and submit a
patch against a more recent version of CURL. Thanks again!

--
Chad Monroe


Received on 2009-05-14