Trivial File Transfer
Protocol, or (TFTP
Although FTP is the most general file transfer
protocol in the TCP/IP suite. Many applications do
not need the full functionality FTP offers, nor can
they afford the complexity. For example, FTP
requires clients and servers to manage multiple
concurrent TCP connections, something that may
be difficult or impossible on personal computers
that do not have sophisticated operating systems.
The TCP/IP suite contains a second file transfer
protocol that provides inexpensive,
unsophisticated service. Known as the Trivial
File Transfer Protocol, or (TFTP), it is intended
for applications that do not need complex
interactions between the client and server. TFTP
restricts operations to simple file transfers and
does not provide authentication. Because it is
more restrictive, TFTP software is much smaller
than FTP.
Unlike FTP, TFTP does not need a reliable stream
transport service. It runs on top of UDP or any other
unreliable packet delivery system, using timeout and
retransmission to ensure that data arrives. The
sending side transmits a file in fixed size (512 byte)
blocks and awaits an acknowledgement for each
block before sending the next. The receiver
acknowledges each block upon receipt.
The rules for TFTP are simple. The first packet sent
requests a file transfer and establishes the interaction
between client and server - the packet specifies a file
name and whether the file will be read (transferred to
the client) or written (transferred to the server).
Blocks of the file are numbered consecutively starting
at 1. Each data packet contains a header that
specifies the number of the block it carries, and each
acknowledgement contains the number of the block
being acknowledged. A block of less than 512 bytes
signals the end of file. It is possible to send an error
message either in the place of data or an
acknowledgement; errors terminate the transfer.
Figure shows the format of the five TFTP
packet types. The initial packet must use
operation codes 1 or 2, specify either a read
request or a write request, the FILENAME
field to specify the name of a file, and the
MODE field to specify whether the client will
read the file, write the file or both.
Once a read or write request has been made, the
server uses the IP address and UDP protocol port
number of the client to identify subsequent
operations. Thus, neither data messages (the
messages that carry blocks from the file) nor ack
messages (the messages that acknowledge data
blocks) need to specify the file name. The final
message type illustrated in Figure is used to report
errors. Lost messages can be retransmitted after a
timeout, but most other errors simply cause
termination of the interaction.
TFTP retransmission is unusual because it is
symmetric. Each side implements a timeout and
retransmission. If the side sending data times out,
it retransmits the last data block. If the side
responsible for acknowledgements times out, it
retransmits the last acknowledgement. Having both
sides participate in retransmission helps ensure
that transfer will not fail after a single packet loss.
While symmetric retransmission guarantees
robustness, it can lead to excessive
retransmissions. The problem, known as the
Sorcerer's Apprentice Bug, arises when an
acknowledgement for data packet k is delayed, but
not lost. The sender retransmits the data packet,
which the receiver acknowledges.
Both acknowledgements eventually arrive, and
each triggers a transmission of data packet k+l.
The receiver will acknowledge both copies of data
packet k+l, and the two acknowledgements will
each cause the sender to transmit data packet
k+2. The Sorcerer's Apprentice Bug can also start
if the underlying internet duplicates packets. Once
started, the cycle continues indefinitely with each
data packet being transmitted exactly twice.
