On Mon, 29 Aug 2005, John Kelly wrote:

> I am about ready to start testing a patch that implements TFTP support in
> curl. I want to run some of the implementation design issues past you
> before posting the patch.

Cool. Nice to see you getting results so soon!

> The tricky part comes in lib/connect.c in singleipconnect, where the connect
> call is made on the network socket. Here, I put a ai_socktype==SOCK_STREAM
> conditional around the connect call, and just passed through an rc=0 success
> assignment otherwise.

Seems logical.

> I set the ai_socktype to SOCK_DGRAM based on PROT_TFTP in conn->protocol in
> Curl_getaddrinfo (lib/hostip6.c) and based on port in Curl_he2ai
> (lib/hostip4.c). It seems like conn->protocol is the more robust test, but
> conn is not passed into Curl_he2ai.

It probably should changed to that.

> It might be cleaner to put some tcp/upd flag in connectdata that would be
> set when the URL is parsed--since I can't see any other UDP protocols on the
> horizon, I took the easier route.

Quite OK with me. It isn't such a big deal, and if we add another UDP protocol
in the future we can very well change it then!

> Initially, I had hoped to hook the tftp transfer into the Curl_readwrite,
> but that seemed pretty intrusive, and swrite and sread would have to be
> modified to use sendto/recvfrom based on socktype. Instead, I used the
> telnet approach, and implemented the transfer entirely within a new
> Curl_tftp. The implementations are in lib/tftp.c with prototypes
> lib/tftp.h; Makefile.inc is modified to include them.

The downside of this approach is that when taking the telnet approach, you
also end up in the same league as telnet: the lesser good one. telnet is badly
supported within libcurl, and it can't be used at all with the multi interface
for this very reason.

I don't blame you for picking the easier route, not even if you decide to
leave it like this, but it would still be an item to fix (just like the telnet
implementation is an item to fix atm) in the future. (Not to mention that the
telnet code waits on stdin which is terrible for a lib to do, and breaks the
code's ability to get moved to the main loop since files aren't select()able
on all platforms.)

> There was also a "feedback" note about RFC 3617. I didn't see anywhere that
> this ";mode=" parsing is done already, and it seems like the "-B" flag is
> already in use for FTP, so I just used that to select "netascii" mode
> instead of a default "octet".

The ";mode=" parsing is called ";type=" in FTP URLs and is done in the
FTP-specific parts in lib/url.c (around line 2840 in my version).

> It also seems like there are two abitrary parameters in my Curl_tftp--the
> select() timeout interval and the maximum number of retries to attempt.
> Should I add CURLOPTs for these to give users control over them?

Isn't the timeout better fit to use the regular libcurl timeout?

The retry number, is that for retrying one of the TFTP packages in case of no
ACK or similar (I'm really not skilled in TFTP protocol details - yet)? If so,
I figure a CURLOPT for it is suitable. With a reasonable default of course.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html