>>>>> "re" == Robert Elz <kre%munnari.OZ.AU@localhost> writes: re> How is the recipient supposed to know it is a duplicate, and re> wait for the other copy of the next-time around block N re> instead? embed a crc in the downloaded file and reboot if it doesn't verify. :) re> think to what the original intent was - tftp was invented in re> the late 1970's re> ps: if we need more confirmation of this, we can just ask Noel re> Chiappa, who is credited in rfc738 as the inventor of TFTP. are you designing a functioning museum piece, or a tftp server? It is a serious question with two right answers. re> Lastly, using TFTP to transfer files this big is not rational, re> even today. agreed! They could just use NFSv2 like a NetBSD stage2---no need even to resort to TCP. but what they should have done is maybe not a good reason to stubbornly desupport it, given actual experience with clients that exist (i guess windows pxe booting and some cisco access point, so far). i've been using linux tftpd-hpa because the netbsd tftpd didn't work with the client inside the alpha XP1000 srm. That's a Digital proprietary client, and of course among NetBSD, Digital can do no wrong, correct? IIRC it was some options-negotiation garbage. :/ I don't really care about fixing it, but the point is, it might be appropriate to intentionally allow the tftp server to be a repository of historical kludges for dealing with the various weird client implementations people have encountered over the years. Often when one is using a tftp server, the client is proprietary software. Even as a museum piece, recording these kludges is probably a more worthy goal than perfecting the elegance of the Great Noel Chiappa's masterful 1970's Final Solution to the File Transfer Problem.
Description: PGP signature