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