TFTP客户端-C语言实现

Network Working Group K. Sollins

Request For Comments: 1350 MIT

STD: 33 July 1992

Obsoletes: RFC 783

THE TFTP PROTOCOL (REVISION 2)

Status of this Memo

This RFC specifies an IAB standards track protocol for the Internet

community, and requests discussion and suggestions for improvements.

Please refer to the current edition of the "IAB Official Protocol

describes the protocol and its types of packets. The document also

explains the reasons behind some of the design decisions.

Acknowlegements

The protocol was originally designed by Noel Chiappa, and was

redesigned by him, Bob Baldwin and Dave Clark, with comments from

Steve Szymanski. The current revision of the document includes

modifications stemming from discussions with and suggestions from

Larry Allen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald,

Liza Martin, David Reed, Craig Milo Rogers (of USC-ISI), Kathy

Yellick, and the author. The acknowledgement and retransmission

Research under contract number N00014-75-C-0661.

1. Purpose

TFTP is a simple protocol to transfer files, and therefore was named

the Trivial File Transfer Protocol or TFTP. It has been implemented

on top of the Internet User Datagram protocol (UDP or Datagram) [2]

Sollins [Page 1]

RFC 1350 TFTP Revision 2 July 1992

so it may be used to move files between machines on different

networks implementing UDP. (This should not exclude the possibility

of implementing TFTP on top of other datagram protocols.) It is

designed to be small and easy to implement. Therefore, it lacks most

of the features of a regular FTP. The only thing it can do is read

and write files (or mail) from/to a remote server. It cannot list

directories, and currently has no provisions for user authentication.

data.

Three modes of transfer are currently supported: netascii (This is

[1] with the modifications specified in "Telnet Protocol

Specification" [3].) Note that it is 8 bit ascii. The term

"netascii" will be used throughout this document to mean this

2. Overview of the Protocol

Any transfer begins with a request to read or write a file, which

request, the connection is opened and the file is sent in fixed

length blocks of 512 bytes. Each data packet contains one block of

data, and must be acknowledged by an acknowledgment packet before the

next packet can be sent. A data packet of less than 512 bytes

signals termination of a transfer. If a packet gets lost in the

network, the intended recipient will timeout and may retransmit his

last packet (which may be data or an acknowledgment), thus causing

acknowledgments, the other sends acknowledgments and receives data.

signalled by sending an error packet. This packet is not

acknowledged, and not retransmitted (i.e., a TFTP server or user may

terminate after sending an error message), so the other end of the

connection may not get it. Therefore timeouts are used to detect

such a termination when the error packet has been lost. Errors are

Sollins [Page 2]

RFC 1350 TFTP Revision 2 July 1992

caused by three types of events: not being able to satisfy the

request (e.g., file not found, access violation, or no such user),

receiving a packet which cannot be explained by a delay or

duplication in the network (e.g., an incorrectly formed packet), and

losing access to a necessary resource (e.g., disk full or access

denied during a transfer).

termination, the source port of a received packet being incorrect.

In this case, an error packet is sent to the originating host.

implementation. For example, the fixed length blocks make allocation

straight forward, and the lock step acknowledgement provides flow

control and eliminates the need to reorder incoming data packets.

transport medium. As shown in Figure 3-1, the order of the contents

of a packet will be: local medium header, if used, Internet header,

Datagram header, TFTP header, followed by the remainder of the TFTP

packet. (This may or may not be data depending on the type of packet

values in the Internet header. On the other hand, the source and

destination port fields of the Datagram header (its format is given

in the appendix) are used by TFTP and the length field reflects the

size of the TFTP packet. The transfer identifiers (TID’s) used by

TFTP are passed to the Datagram layer to be used as ports; therefore

they must be between 0 and 65,535. The initialization of TID’s is

discussed in the section on initial connection protocol.

Sollins [Page 3]

RFC 1350 TFTP Revision 2 July 1992

---------------------------------------------------

| Local Medium | Internet | Datagram | TFTP |

---------------------------------------------------

Figure 3-1: Order of Headers

A transfer is established by sending a request (WRQ to write onto a

foreign file system, or RRQ to read from it), and receiving a

packet for read. In general an acknowledgment packet will contain

the block number of the data packet being acknowledged. Each data

packet has associated with it a block number; block numbers are

TID for itself, to be used for the duration of that connection. The

TID’s chosen for a connection should be randomly chosen, so that the

probability that the same number is chosen twice in immediate

succession is very low. Every packet has associated with it the two

destination TID. These TID’s are handed to the supporting UDP (or

other datagram protocol) as the source and destination ports. A

requesting host chooses its source TID as described above, and sends

its initial request to the known TID 69 decimal (105 octal) on the

serving host. The response to the request, under normal operation,

uses a TID chosen by the server as its source TID and the TID chosen

for the previous message by the requestor as its destination TID.

respectively. The appendix contains a similar example for reading a

Sollins [Page 4]