cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: TFTP Option Negotiation

From: Chad Monroe <cmonroe_at_occamnetworks.com>
Date: Sat, 27 Dec 2008 12:33:37 -0800

On Dec 25, 2008, at 6:47 AM, Daniel Stenberg wrote:

> On Wed, 24 Dec 2008, Chad Monroe wrote:
>
>> 1.) I think it would be best to set the blksize to 512 as this is
>> the TFTP default (and what libcurl uses today, but allow the user
>> to specify their own block size prior to calling perform. Would you
>> recommend doing this through the curl_easy_setopt() interface? If
>> so, does CURLOPT_TFTP_BLKSIZE work for you?
>
> Yes, I think 512 is the only sane default and a new setopt option
> sounds like the only available way to set this. Existing options
> such as CURLOPT_BUFFERSIZE can't be used for this.
>
>> 2.) RFC 2348 allows for a block size varying from 8 to 65464 bytes.
>> Today rpacket and spacket are statically allocated in the
>> tftp_state_data_t struct as the block size is fixed. I'd hate to
>> always statically allocate 65464+4 bytes for s/rpacket as most
>> users will be using the default block size anyway; it'd be a waste.
>> I was thinking of making s/rpacket pointers in the
>> tftp_state_data_t struct and allocating them based on whatever the
>> user specifies via CURLOPT_TFTP_BLKSIZE, or 512+4 if the user does
>> not specify this option. If this seems like a good approach to you,
>> where should I free the memory allocated for these two packet
>> buffers?
>
> I think it makes sense to keep the buffer around even after DONE
> (when a single transfer is completed) in case multiple transfers are
> done from the same "connection" and instead do the free at
> DISCONNECT time (even though UDP doesn't quite use disconnects the
> paradigm is still used internally even for TFTP).
>
> Note: the 'disconnect' function is currently not set in the
> Curl_handler_tftp struct so it needs to be set there to point to a
> suitable function.
>
>> Pending answers to these questions and some testing on my end I
>> should have a patch shortly for you to take a look at.
>
> I'm looking forward to it! Oh, and it would be great if you also
> could take a look and see if you can extend/make the test suite's
> TFTP-server to support this and excerise some of this new logic in a
> test case or two.
>
> --
>
> / daniel.haxx.se

Hi Daniel,

I have the libcurl code done according to what we've talked about in
this thread, but am struggling a bit adding some test cases. I ran
through all of the existing test cases today and they run fine with
the new code in place, but it doesn't test the option negotiation at
all. I looked at and started modifying the test TFTP server code a bit
but am not happy with the results yet. Would you like me to add full
option negotiation support to the server side as well so we can add
test cases which use varying block sizes, or is there some other way
you'd prefer to see this done? Adding option negotiation support to
the test server is probably as much or more work than adding it to
libcurl, so I want to make sure this is something necessary before
finishing the work.

Also, since I have the library code mostly complete, I could submit
that patch in the near future and continue to work on updating the
test server later, or I could wait until it's all done and submit one
big patch, though it will probably take a bit longer. Whatever
approach is easiest for you works for me. So far these are the files
I've had to modify within libcurl:

docs/libcurl/curl_easy_setopt.3
include/curl/curl.h
lib/tftp.c
lib/url.c
lib/urldata.h

Thanks again for the help!

--
Chad Monroe
Received on 2008-12-27