TFTP Protocol Tutorial


What is TFTP Protocol?

TFTP stands for Trivial File Transfer Protocol. That is for the liter version for a file transfer application. As the name suggests it is a protocol used to transfer files and data. To undergo this process of file transferring and receiving between machines of different networks, TFTP Protocol uses UDP (User Datagram Protocol). TFTP protocol consists of various types of small packets, which are considered as individual units, which makes it easier to be transferred. The standard is defined in IETF spec RFC1350.

On most of the systems, we use a file transfer protocol (FTP) with more capability.

What is FTP Protocol?

FTP stands for File Transfer Protocol. It is used to transfer files and data over the internet. The process of file or data transfer within an organization or over the internet is made possible and easy with the help of FTP Protocol.

One of the first solutions to the problem of heavy data transfer was FTP Protocol. Due to its effectiveness, it became one of the widely used protocols to undergo the transfer process which otherwise was cumbersome.

 

FTP VS TFTP Protocol:

Although both the protocols are used to transfer files and data from one computer to another, yet there are some significant differences between them. Some of the points of variation are as follows:

 

  • Size of Software – The size of the software is one of the key points of difference. On one hand, where FTP Protocol has a very large size, the TFTP Protocol has a relatively smaller size.

 

  • Ports- The FTP Protocol works on two ports viz. 20 and 21 whereas TFTP Protocol works on a single port.

 

  • Service Provider- The service provider in both the case is different. FTP uses TCP ( Transmission Control Protocol) whereas TFTP uses UDP ( User Datagram Protocol).

 

  • Complexity- The FTP protocol is highly complex as compared to the TFTP protocol.

 

  • Messages- The FTP protocol has a provision of a number of messages as opposed to the TFTP protocol which has only five messages.

 

Developers of TFTP Protocol

A number of people contributed to the later enhancements of the TFTP Protocol, but at first Noel Chiappa developed it. Later on, he along with Bob Baldwin and Dave Clark redesigned the protocol with inputs from Steve Szymanski.  This was not the end, they continued working on it. After extensive discussions and proposals from Larry Allen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald, Liza Martin, David Reed, Craig Milo Rogers (of USC-ISI), Kathy Yellick, and K. Sollins, the latest version of the protocol was introduced.

How Does TFTP Protocol Work?

For the transfer process to start, the primary requirement is that the server forms a connection so that it can read or write the files to be transferred. Once the connection is established, the procedure to send the files begins.  These files are transferred in small data packets of fixed length blocks of 512 bytes. These data packets are further divided into blocks, and each packet consists of one block. Once a data pack is sent it needs to be acknowledged by the acknowledgment packet before sending the other packet.

Now for it to be transferred completely and be acknowledged, the packet should be a minimum of 512 bytes. If the size of the packet is less than 512 bytes, it leads to the termination of the packet. This, in turn, causes a timeout of the transferring process and the sender has to retransmit the packet.

One important thing to keep in mind is that both the machines involved in the process are taken into account as a sender and a receiver. This is so because while one transmits data and receives an acknowledgment, the other transmits acknowledgment and accepts the data.

 

Now during this process of transmission, at times there occurs an error. This leads to the termination of the connection. Unlike the other packets, when the error packet is sent it is neither acknowledged nor retransmitted. This is the reason that there are timeouts, as they make it easier for us to detect the error packet.

 

The reason behind the occurrence of error could be three, namely:

  • Unable to fulfill the demand; for example, file not found, access violation, or no such user
  • Accepting a packet that can’t be clarified by a postponement or duplication in the organization, for example, an incorrectly formed packet, and
  • No longer have the access to a necessary resource; for example, disk full or access denied during a transfer

Now as is mentioned above, TFTP usually recognizes almost all the error packets lead to termination except for one condition wherein the source port of a packet is incorrect.  Subsequently, an error packet is sent to the originating host.

 

Correlation With Other Protocols

As we have read in this article earlier as well, the TFTP protocol is devised to be implemented on UDP. Since Datagram is actualized on the Internet convention, parcels will have an Internet header, a Datagram header, and a TFTP header.

As is visible from Figure 1 below, the headers in the packet have to be in the order as mentioned.

 

—————————————————————-

|  Local Medium  |  Internet  |  Datagram  |  TFTP  |

—————————————————————-

Figure 1

 

 

TFTP Packets

The TFTP protocol supports the following five types of packets:

 

Message codes for TFTP protocol Operations

  1. Read Request (RRQ)
  2. Write Request (WRQ)
  3. Data (DATA)
  4. Acknowledgment (ACK)
  5. Error (ERROR)

 

As mentioned above, the headers of a packet follow a specific order. Similarly, they also contain the Opcode associated with that packet. The following figure shows an example of how the TFTP header of a packet actually looks like.

2 bytes           string 1-byte string         1 byte

———————————————————————-

|    Opcode   |   Filename   |       0       |     Mode      |       0      |

———————————————————————–

Figure 2: RRQ/WRQ packet

 

Looking at the example above, we can see that the RRQ and WRQ packets with Opcode 1 and 2 respectively occur in the packet. The second header of the packet is the filename, which is a sequence of bytes in netascii terminated by a zero byte. Thereafter comes the mode string, which can contain either of  “netascii”, “octet” or “mail”.

A host, which gets netascii mode information, must make an interpretation of the information to its own design. If a machine has the file in the 8-bit format, we use Octet mode to transfer that file.  Lastly, whenever the Mail mode is used, it uses the name of the mail recipient instead of the file. Also, one unique feature of Mail mode is that it always begins with a WRQ.

 

Looking a data, it is transferred as DATA packets as shown below.

2 bytes      2 bytes         n bytes                                                       ——————————————–                                                    |  Opcode  |    Block #   |     Data     |                                                        ——————————————–                                                                  Figure 3: DATA packet

 

The format for DATA packets as is visible from the figure is Opcode i.e. 3, a block number and a data field. Once the data packet follows all the laid rules it is sent.

This process continues. The first ACK packet forms the acknowledgment of the previous DATA packet sent.  Once this process of transmission takes place, ACK or ERROR packets acknowledge the WRQ and DATA packets whereas; DATA or ERROR packets acknowledge RRQ and ACK packets.