>>>>> "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.
Attachment:
pgpKFUv8yUo32.pgp
Description: PGP signature