tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: tftp protocol

>>>>> "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

Home | Main Index | Thread Index | Old Index