🚀 go-pugleaf

THAT IS NOT A BUG!!

The ORIGINAL tftp spec required retransmisson of ack's, as well
as of data packets, upon receiving any old packet.  This algorithm
was shown to be faulty by Michael Greenwald at MIT.  It has the
following problem:

    Suppose host A is talking to host B.  Suppose further that host
    A's retransmit timeout is too short (a common case, since there is
    no good way to determine an initial retransmit timeout).  Now
    observe what happens:

    Host A sends packet 1

    Host A's retransmit timer goes
    off, and host A retransmits packet
    1.
                                        Host B receives packet 1, sends
                                        ack 1.
    Host A receives ack 1, sends
    packet 2. 
                                        Host B receives retransmitted packet
                                        1, retransmits ack 1.
    Host A receives retransmitted
    ack 1, retransmits packet 2.
                                        Host B receives packet 2, sends
                                        ack 2.
    Host A receives ack 2, sends
    packet 3.
                                        Host B receives retransmitted packet
                                        2, retransmits ack 2.
    Host A receives retransmitted
    ack 2, retransmits packet 3.
                .                                       .
                .                                       .
                .                                       .

Note that what has now happened is that every tftp packet is being transmitted
twice.  Furthermore, if Host A's retransmit timer goes off too early again,
every packet will be transmitted three times, and so forth.  This quickly
causes tftp performance to degrade to zero, and connections eventually time
out.

The current tftp spec avoids this problem by specifying that only data packets
are to be retransmitted in response to receipt of an old ack, and then only if
the ack is for the previously transmitted data packet.  Acks are retransmitted
ONLY when the retransmit timer expires.  I believe that this is the way the
Berkeley tftp currently (and correctly) behaves, and hence that Ron's "bug fix"
is in fact unnecessary and incorrect.

There are several other problems with the 4.2bsd tftp as distributed, including:
    1) No support for netascii mode.
    2) Relies on signals breaking through read() calls; this no longer
	   happens in 4.2 (instead the read() call is restarted after a signal).
    3) Uses the same buffer for transmit and receive, thereby clobbering the
       packet to be retransmitted if an old packet arrives.
    4) Several other problems in the retransmit code.

I believe that the PC/IP people at MIT are shipping a completely new tftp implementation
for 4.2bsd as part of their PC/IP package.  I suggest contacting John Romkey at MIT
(romkey@mit-borax.mit.edu, I think) for further information.
                                                -Larry Allen
                                                 Apollo Computer