Hi Daniel,

Thanks for the reply. I think I've got this mostly implemented but
have two questions:

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?

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?

Pending answers to these questions and some testing on my end I should
have a patch shortly for you to take a look at.

--
Chad Monroe
On Dec 23, 2008, at 3:38 PM, Daniel Stenberg wrote:
> On Tue, 23 Dec 2008, Chad Monroe wrote:
>
>> I plan to use libcurl to perform FTP and TFTP downloads within an  
>> application I am writing an am curious if there is any specific  
>> reason why libcurl does not support TFTP option negotiation.
>
> [...]
>
>> If this support doesn't exist simply because no one has added it  
>> yet, I'd be happy to add it. If it is for some other reason, I'm  
>> curious as to why.
>
> I'm not aware of any particular reason and I think we'd be in favour  
> of improving the TFTP support to make it really good! So by all  
> means, please jump in and start working! ;-)
>
> -- 
>
> / daniel.haxx.se