📄 417.htm
字号:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>CTerm非常精华下载</title>
</head>
<body bgcolor="#FFFFFF">
<table border="0" width="100%" cellspacing="0" cellpadding="0" height="577">
<tr><td width="32%" rowspan="3" height="123"><img src="DDl_back.jpg" width="300" height="129" alt="DDl_back.jpg"></td><td width="30%" background="DDl_back2.jpg" height="35"><p align="center"><a href="http://202.112.58.200"><font face="黑体"><big><big>Tsinghua</big></big></font></a></td></tr>
<tr>
<td width="68%" background="DDl_back2.jpg" height="44"><big><big><font face="黑体"><p align="center"> 嵌入式系统 (BM: turbolinux jacobw) </font></big></big></td></tr>
<tr>
<td width="68%" height="44" bgcolor="#000000"><font face="黑体"><big><big><p align="center"></big></big><a href="http://cterm.163.net"><img src="banner.gif" width="400" height="60" alt="banner.gif"border="0"></a></font></td>
</tr>
<tr><td width="100%" colspan="2" height="100" align="center" valign="top"><br><p align="center">[<a href="嵌入式系统.htm">回到开始</a>][<a href="398.htm">上一层</a>][<a href="418.htm">下一篇</a>]
<hr><p align="left"><small>发信人: hellow (收复台湾是我心), 信区: Embedded <br>
标 题: TFTP <br>
发信站: BBS 水木清华站 (Sun Nov 5 09:30:15 2000) <br>
<br>
<br>
Network Working Group K. Sollins <br>
Request For Comments: 1350 MIT <br>
STD: 33 July 1992 <br>
Obsoletes: RFC 783 <br>
THE TFTP PROTOCOL (REVISION 2) <br>
Status of this Memo <br>
This RFC specifies an IAB standards track protocol for the Internet <br>
community, and requests discussion and suggestions for improvements. <br>
Please refer to the current edition of the "IAB Official Protocol <br>
Standards" for the standardization state and status of this protocol. <br>
Distribution of this memo is unlimited. <br>
Summary <br>
TFTP is a very simple protocol used to transfer files. It is from <br>
this that its name comes, Trivial File Transfer Protocol or TFTP. <br>
Each nonterminal packet is acknowledged separately. This document <br>
describes the protocol and its types of packets. The document also <br>
explains the reasons behind some of the design decisions. <br>
Acknowlegements <br>
The protocol was originally designed by Noel Chiappa, and was <br>
redesigned by him, Bob Baldwin and Dave Clark, with comments from <br>
Steve Szymanski. The current revision of the document includes <br>
modifications stemming from discussions with and suggestions from <br>
Larry Allen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald, <br>
Liza Martin, David Reed, Craig Milo Rogers (of USC-ISI), Kathy <br>
Yellick, and the author. The acknowledgement and retransmission <br>
scheme was inspired by TCP, and the error mechanism was suggested by <br>
PARC's EFTP abort message. <br>
The May, 1992 revision to fix the "Sorcerer's Apprentice" protocol <br>
bug [4] and other minor document problems was done by Noel Chiappa. <br>
This research was supported by the Advanced Research Projects Agency <br>
of the Department of Defense and was monitored by the Office of Naval <br>
Research under contract number N00014-75-C-0661. <br>
1. Purpose <br>
TFTP is a simple protocol to transfer files, and therefore was named <br>
the Trivial File Transfer Protocol or TFTP. It has been implemented <br>
on top of the Internet User Datagram protocol (UDP or Datagram) [2] <br>
Sollins [Page 1] <br>
<br>
RFC 1350 TFTP Revision 2 July 1992 <br>
so it may be used to move files between machines on different <br>
networks implementing UDP. (This should not exclude the possibility <br>
of implementing TFTP on top of other datagram protocols.) It is <br>
designed to be small and easy to implement. Therefore, it lacks most <br>
of the features of a regular FTP. The only thing it can do is read <br>
and write files (or mail) from/to a remote server. It cannot list <br>
directories, and currently has no provisions for user authentication. <br>
In common with other Internet protocols, it passes 8 bit bytes of <br>
data. <br>
Three modes of transfer are currently supported: netascii (This is <br>
ascii as defined in "USA Standard Code for Information Interchange" <br>
[1] with the modifications specified in "Telnet Protocol <br>
Specification" [3].) Note that it is 8 bit ascii. The term <br>
"netascii" will be used throughout this document to mean this <br>
particular version of ascii.); octet (This replaces the "binary" mode <br>
of previous versions of this document.) raw 8 bit bytes; mail, <br>
netascii characters sent to a user rather than a file. (The mail <br>
mode is obsolete and should not be implemented or used.) Additional <br>
modes can be defined by pairs of cooperating hosts. <br>
Reference [4] (section 4.2) should be consulted for further valuable <br>
directives and suggestions on TFTP. <br>
2. Overview of the Protocol <br>
Any transfer begins with a request to read or write a file, which <br>
also serves to request a connection. If the server grants the <br>
request, the connection is opened and the file is sent in fixed <br>
length blocks of 512 bytes. Each data packet contains one block of <br>
data, and must be acknowledged by an acknowledgment packet before the <br>
next packet can be sent. A data packet of less than 512 bytes <br>
signals termination of a transfer. If a packet gets lost in the <br>
network, the intended recipient will timeout and may retransmit his <br>
last packet (which may be data or an acknowledgment), thus causing <br>
the sender of the lost packet to retransmit that lost packet. The <br>
sender has to keep just one packet on hand for retransmission, since <br>
the lock step acknowledgment guarantees that all older packets have <br>
been received. Notice that both machines involved in a transfer are <br>
considered senders and receivers. One sends data and receives <br>
acknowledgments, the other sends acknowledgments and receives data. <br>
Most errors cause termination of the connection. An error is <br>
signalled by sending an error packet. This packet is not <br>
acknowledged, and not retransmitted (i.e., a TFTP server or user may <br>
terminate after sending an error message), so the other end of the <br>
connection may not get it. Therefore timeouts are used to detect <br>
such a termination when the error packet has been lost. Errors are <br>
Sollins [Page 2] <br>
<br>
<br>
RFC 1350 TFTP Revision 2 July 1992 <br>
caused by three types of events: not being able to satisfy the <br>
request (e.g., file not found, access violation, or no such user), <br>
receiving a packet which cannot be explained by a delay or <br>
duplication in the network (e.g., an incorrectly formed packet), and <br>
losing access to a necessary resource (e.g., disk full or access <br>
denied during a transfer). <br>
TFTP recognizes only one error condition that does not cause <br>
termination, the source port of a received packet being incorrect. <br>
In this case, an error packet is sent to the originating host. <br>
This protocol is very restrictive, in order to simplify <br>
implementation. For example, the fixed length blocks make allocation <br>
straight forward, and the lock step acknowledgement provides flow <br>
control and eliminates the need to reorder incoming data packets. <br>
3. Relation to other Protocols <br>
As mentioned TFTP is designed to be implemented on top of the <br>
Datagram protocol (UDP). Since Datagram is implemented on the <br>
Internet protocol, packets will have an Internet header, a Datagram <br>
header, and a TFTP header. Additionally, the packets may have a <br>
header (LNI, ARPA header, etc.) to allow them through the local <br>
transport medium. As shown in Figure 3-1, the order of the contents <br>
of a packet will be: local medium header, if used, Internet header, <br>
Datagram header, TFTP header, followed by the remainder of the TFTP <br>
packet. (This may or may not be data depending on the type of packet <br>
as specified in the TFTP header.) TFTP does not specify any of the <br>
values in the Internet header. On the other hand, the source and <br>
destination port fields of the Datagram header (its format is given <br>
in the appendix) are used by TFTP and the length field reflects the <br>
size of the TFTP packet. The transfer identifiers (TID's) used by <br>
TFTP are passed to the Datagram layer to be used as ports; therefore <br>
they must be between 0 and 65,535. The initialization of TID's is <br>
discussed in the section on initial connection protocol. <br>
The TFTP header consists of a 2 byte opcode field which indicates <br>
the packet's type (e.g., DATA, ERROR, etc.) These opcodes and the <br>
formats of the various types of packets are discussed further in the <br>
section on TFTP packets. <br>
Sollins [Page 3] <br>
<br>
RFC 1350 TFTP Revision 2 July 1992 <br>
--------------------------------------------------- <br>
| Local Medium | Internet | Datagram | TFTP | <br>
--------------------------------------------------- <br>
Figure 3-1: Order of Headers <br>
4. Initial Connection Protocol <br>
A transfer is established by sending a request (WRQ to write onto a <br>
foreign file system, or RRQ to read from it), and receiving a <br>
positive reply, an acknowledgment packet for write, or the first data <br>
packet for read. In general an acknowledgment packet will contain <br>
the block number of the data packet being acknowledged. Each data <br>
packet has associated with it a block number; block numbers are <br>
consecutive and begin with one. Since the positive response to a <br>
write request is an acknowledgment packet, in this special case the <br>
block number will be zero. (Normally, since an acknowledgment packet <br>
is acknowledging a data packet, the acknowledgment packet will <br>
contain the block number of the data packet being acknowledged.) If <br>
the reply is an error packet, then the request has been denied. <br>
In order to create a connection, each end of the connection chooses a <br>
TID for itself, to be used for the duration of that connection. The <br>
TID's chosen for a connection should be randomly chosen, so that the <br>
probability that the same number is chosen twice in immediate <br>
succession is very low. Every packet has associated with it the two <br>
TID's of the ends of the connection, the source TID and the <br>
destination TID. These TID's are handed to the supporting UDP (or <br>
other datagram protocol) as the source and destination ports. A <br>
requesting host chooses its source TID as described above, and sends <br>
its initial request to the known TID 69 decimal (105 octal) on the <br>
serving host. The response to the request, under normal operation, <br>
uses a TID chosen by the server as its source TID and the TID chosen <br>
for the previous message by the requestor as its destination TID. <br>
The two chosen TID's are then used for the remainder of the transfer. <br>
As an example, the following shows the steps used to establish a <br>
connection to write a file. Note that WRQ, ACK, and DATA are the <br>
names of the write request, acknowledgment, and data types of packets <br>
respectively. The appendix contains a similar example for reading a <br>
file. <br>
Sollins [Page 4] <br>
<br>
RFC 1350 TFTP Revision 2 July 1992 <br>
1. Host A sends a "WRQ" to host B with source= A's TID, <br>
destination= 69. <br>
2. Host B sends a "ACK" (with block number= 0) to host A with <br>
source= B's TID, destination= A's TID. <br>
At this point the connection has been established and the first data <br>
packet can be sent by Host A with a sequence number of 1. In the <br>
next step, and in all succeeding steps, the hosts should make sure <br>
that the source TID matches the value that was agreed on in steps 1 <br>
and 2. If a source TID does not match, the packet should be <br>
discarded as erroneously sent from somewhere else. An error packet <br>
should be sent to the source of the incorrect packet, while not <br>
disturbing the transfer. This can be done only if the TFTP in fact <br>
receives a packet with an incorrect TID. If the supporting protocols <br>
do not allow it, this particular error condition will not arise. <br>
The following example demonstrates a correct operation of the <br>
protocol in which the above situation can occur. Host A sends a <br>
request to host B. Somewhere in the network, the request packet is <br>
duplicated, and as a result two acknowledgments are returned to host <br>
A, with different TID's chosen on host B in response to the two <br>
requests. When the first response arrives, host A continues the <br>
connection. When the second response to the request arrives, it <br>
should be rejected, but there is no reason to terminate the first <br>
connection. Therefore, if different TID's are chosen for the two <br>
connections on host B and host A checks the source TID's of the <br>
messages it receives, the first connection can be maintained while <br>
the second is rejected by returning an error packet. <br>
5. TFTP Packets <br>
TFTP supports five types of packets, all of which have been mentioned <br>
above: <br>
opcode operation <br>
1 Read request (RRQ) <br>
2 Write request (WRQ) <br>
3 Data (DATA) <br>
4 Acknowledgment (ACK) <br>
5 Error (ERROR) <br>
The TFTP header of a packet contains the opcode associated with <br>
that packet. <br>
Sollins [Page 5] <br>
<br>
RFC 1350 TFTP Revision 2 July 1992 <br>
2 bytes string 1 byte string 1 byte <br>
------------------------------------------------ <br>
| Opcode | Filename | 0 | Mode | 0 | <br>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -