<html xmlns="http://www.w3.org/1999/xhtml"><head><meta charset="utf-8"><meta name="generator" content="pdf2htmlEX"><meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"><link rel="stylesheet" href="https://csdnimg.cn/release/download_crawler_static/css/base.min.css"><link rel="stylesheet" href="https://csdnimg.cn/release/download_crawler_static/css/fancy.min.css"><link rel="stylesheet" href="https://csdnimg.cn/release/download_crawler_static/2529827/raw.css"><script src="https://csdnimg.cn/release/download_crawler_static/js/compatibility.min.js"></script><script src="https://csdnimg.cn/release/download_crawler_static/js/pdf2htmlEX.min.js"></script><script>try{pdf2htmlEX.defaultViewer = new pdf2htmlEX.Viewer({});}catch(e){}</script><title></title></head><body><div id="sidebar" style="display: none"><div id="outline"></div></div><div id="pf1" class="pf w0 h0" data-page-no="1"><div class="pc pc1 w0 h0"><img class="bi x0 y0 w1 h1" alt="" src="https://csdnimg.cn/release/download_crawler_static/2529827/bg1.jpg"><div class="t m0 x1 h2 y1 ff1 fs0 fc0 sc0 ls0 ws0">Network Working Group K. Sollins </div><div class="t m0 x1 h2 y2 ff1 fs0 fc0 sc0 ls0 ws0">Request For Comments: 1350 MIT </div><div class="t m0 x1 h2 y3 ff1 fs0 fc0 sc0 ls0 ws0">STD: 33 July 1992 </div><div class="t m0 x1 h2 y4 ff1 fs0 fc0 sc0 ls0 ws0">Obsoletes: RFC 783 </div><div class="t m0 x1 h2 y5 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y6 ff1 fs0 fc0 sc0 ls0 ws0"> THE TFTP PROTOCOL (REVISION 2) </div><div class="t m0 x1 h2 y7 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y8 ff1 fs0 fc0 sc0 ls0 ws0">Status of this Memo </div><div class="t m0 x1 h2 y9 ff1 fs0 fc0 sc0 ls0 ws0"> This RFC specifies an IAB standards track protocol for the Internet </div><div class="t m0 x1 h2 ya ff1 fs0 fc0 sc0 ls0 ws0"> community, and requests discussion and suggestions for improvements. </div><div class="t m0 x1 h2 yb ff1 fs0 fc0 sc0 ls0 ws0"> Please refer to the current edition of the "IAB Official Protocol </div><div class="t m0 x1 h2 yc ff1 fs0 fc0 sc0 ls0 ws0"> Standards" for the standardization state and status of this protocol. </div><div class="t m0 x1 h2 yd ff1 fs0 fc0 sc0 ls0 ws0"> Distribution of this memo is unlimited. </div><div class="t m0 x1 h2 ye ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x2 h2 yf ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y10 ff1 fs0 fc0 sc0 ls0 ws0">Network Communication Protocol Map. To order: http://www.javvin.com/map.html </div><div class="t m0 x1 h2 y11 ff1 fs0 fc0 sc0 ls0 ws0">Easy to use network sniffing tool: http://www.javvin.com/packet.html </div><div class="t m0 x1 h2 y12 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y13 ff1 fs0 fc0 sc0 ls0 ws0">Summary </div><div class="t m0 x1 h2 y14 ff1 fs0 fc0 sc0 ls0 ws0"> TFTP is a very simple protocol used to transfer files. It is from </div><div class="t m0 x1 h2 y15 ff1 fs0 fc0 sc0 ls0 ws0"> this that its name comes, Trivial File Transfer Protocol or TFTP. </div><div class="t m0 x1 h2 y16 ff1 fs0 fc0 sc0 ls0 ws0"> Each nonterminal packet is acknowledged separately. This document </div><div class="t m0 x1 h2 y17 ff1 fs0 fc0 sc0 ls0 ws0"> describes the protocol and its types of packets. The document also </div><div class="t m0 x1 h2 y18 ff1 fs0 fc0 sc0 ls0 ws0"> explains the reasons behind some of the design decisions. </div><div class="t m0 x1 h2 y19 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y1a ff1 fs0 fc0 sc0 ls0 ws0">Acknowlegements </div><div class="t m0 x1 h2 y1b ff1 fs0 fc0 sc0 ls0 ws0"> The protocol was originally designed by Noel Chiappa, and was </div><div class="t m0 x1 h2 y1c ff1 fs0 fc0 sc0 ls0 ws0"> redesigned by him, Bob Baldwin and Dave Clark, with comments from </div><div class="t m0 x1 h2 y1d ff1 fs0 fc0 sc0 ls0 ws0"> Steve Szymanski. The current revision of the document includes </div><div class="t m0 x1 h2 y1e ff1 fs0 fc0 sc0 ls0 ws0"> modifications stemming from discussions with and suggestions from </div><div class="t m0 x1 h2 y1f ff1 fs0 fc0 sc0 ls0 ws0"> Larry Allen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald, </div><div class="t m0 x1 h2 y20 ff1 fs0 fc0 sc0 ls0 ws0"> Liza Martin, David Reed, Craig Milo Rogers (of USC-ISI), Kathy </div><div class="t m0 x1 h2 y21 ff1 fs0 fc0 sc0 ls0 ws0"> Yellick, and the author. The acknowledgement and retransmission </div><div class="t m0 x1 h2 y22 ff1 fs0 fc0 sc0 ls0 ws0"> scheme was inspired by TCP, and the error mechanism was suggested by </div><div class="t m0 x1 h2 y23 ff1 fs0 fc0 sc0 ls0 ws0"> PARC's EFTP abort message. </div><div class="t m0 x1 h2 y24 ff1 fs0 fc0 sc0 ls0 ws0"> The May, 1992 revision to fix the "Sorcerer's Apprentice" protocol </div><div class="t m0 x1 h2 y25 ff1 fs0 fc0 sc0 ls0 ws0"> bug [4] and other minor document problems was done by Noel Chiappa. </div><div class="t m0 x1 h2 y26 ff1 fs0 fc0 sc0 ls0 ws0"> This research was supported by the Advanced Research Projects Agency </div><div class="t m0 x1 h2 y27 ff1 fs0 fc0 sc0 ls0 ws0"> of the Department of Defense and was monitored by the Office of Naval </div><div class="t m0 x1 h2 y28 ff1 fs0 fc0 sc0 ls0 ws0"> Research under contract number N00014-75-C-0661. </div><div class="t m0 x1 h2 y29 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y2a ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y2b ff1 fs0 fc0 sc0 ls0 ws0">Sollins [Page 1] </div><div class="t m0 x1 h2 y2c ff1 fs0 fc0 sc0 ls1 ws0"> </div></div><div class="pi" data-data='{"ctm":[1.346230,0.000000,0.000000,1.346230,0.000000,0.000000]}'></div></div></body></html>
<div id="pf2" class="pf w0 h0" data-page-no="2"><div class="pc pc2 w0 h0"><img class="bi x0 y0 w1 h1" alt="" src="https://csdnimg.cn/release/download_crawler_static/2529827/bg2.jpg"><div class="t m0 x1 h2 y1 ff1 fs0 fc0 sc0 ls0 ws0">RFC 1350 TFTP Revision 2 July 1992 </div><div class="t m0 x1 h2 y2 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y3 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y4 ff1 fs0 fc0 sc0 ls0 ws0"> 1. Purpose </div><div class="t m0 x1 h2 y5 ff1 fs0 fc0 sc0 ls0 ws0"> TFTP is a simple protocol to transfer files, and therefore was named </div><div class="t m0 x1 h2 y6 ff1 fs0 fc0 sc0 ls0 ws0"> the Trivial File Transfer Protocol or TFTP. It has been implemented </div><div class="t m0 x1 h2 y7 ff1 fs0 fc0 sc0 ls0 ws0"> on top of the Internet User Datagram protocol (UDP or Datagram) [2] </div><div class="t m0 x1 h2 y8 ff1 fs0 fc0 sc0 ls0 ws0"> so it may be used to move files between machines on different </div><div class="t m0 x1 h2 y9 ff1 fs0 fc0 sc0 ls0 ws0"> networks implementing UDP. (This should not exclude the possibility </div><div class="t m0 x1 h2 ya ff1 fs0 fc0 sc0 ls0 ws0"> of implementing TFTP on top of other datagram protocols.) It is </div><div class="t m0 x1 h2 yb ff1 fs0 fc0 sc0 ls0 ws0"> designed to be small and easy to implement. Therefore, it lacks most </div><div class="t m0 x1 h2 yc ff1 fs0 fc0 sc0 ls0 ws0"> of the features of a regular FTP. The only thing it can do is read </div><div class="t m0 x1 h2 yd ff1 fs0 fc0 sc0 ls0 ws0"> and write files (or mail) from/to a remote server. It cannot list </div><div class="t m0 x1 h2 ye ff1 fs0 fc0 sc0 ls0 ws0"> directories, and currently has no provisions for user authentication. </div><div class="t m0 x1 h2 y2d ff1 fs0 fc0 sc0 ls0 ws0"> In common with other Internet protocols, it passes 8 bit bytes of </div><div class="t m0 x1 h2 y2e ff1 fs0 fc0 sc0 ls0 ws0"> data. </div><div class="t m0 x1 h2 y2f ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y30 ff1 fs0 fc0 sc0 ls0 ws0"> Three modes of transfer are currently supported: netascii (This is </div><div class="t m0 x1 h2 y31 ff1 fs0 fc0 sc0 ls0 ws0"> ascii as defined in "USA Standard Code for Information Interchange" </div><div class="t m0 x1 h2 y32 ff1 fs0 fc0 sc0 ls0 ws0"> [1] with the modifications specified in "Telnet Protocol </div><div class="t m0 x1 h2 y33 ff1 fs0 fc0 sc0 ls0 ws0"> Specification" [3].) Note that it is 8 bit ascii. The term<span class="ls1"> </span></div><div class="t m0 x1 h2 y34 ff1 fs0 fc0 sc0 ls0 ws0"> "netascii" will be used throughout this document to mean this </div><div class="t m0 x1 h2 y35 ff1 fs0 fc0 sc0 ls0 ws0"> particular version of ascii.); octet (This replaces the "binary" mode </div><div class="t m0 x1 h2 y36 ff1 fs0 fc0 sc0 ls0 ws0"> of previous versions of this document.) raw 8 bit bytes; mail, </div><div class="t m0 x1 h2 y37 ff1 fs0 fc0 sc0 ls0 ws0"> netascii characters sent to a user rather than a file. (The mail </div><div class="t m0 x1 h2 y38 ff1 fs0 fc0 sc0 ls0 ws0"> mode is obsolete and should not be implemented or used.) Additional </div><div class="t m0 x1 h2 y39 ff1 fs0 fc0 sc0 ls0 ws0"> modes can be defined by pairs of cooperating hosts. </div><div class="t m0 x1 h2 y3a ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y3b ff1 fs0 fc0 sc0 ls0 ws0"> Reference [4] (section 4.2) should be consulted for further valuable </div><div class="t m0 x1 h2 y3c ff1 fs0 fc0 sc0 ls0 ws0"> directives and suggestions on TFTP. </div><div class="t m0 x1 h2 y3d ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y3e ff1 fs0 fc0 sc0 ls0 ws0">2. Overview of the Protocol </div><div class="t m0 x1 h2 y3f ff1 fs0 fc0 sc0 ls0 ws0"> Any transfer begins with a request to read or write a file, which </div><div class="t m0 x1 h2 y40 ff1 fs0 fc0 sc0 ls0 ws0"> also serves to request a connection. If the server grants the </div><div class="t m0 x1 h2 y41 ff1 fs0 fc0 sc0 ls0 ws0"> request, the connection is opened and the file is sent in fixed </div><div class="t m0 x1 h2 y42 ff1 fs0 fc0 sc0 ls0 ws0"> length blocks of 512 bytes. Each data packet contains one block of </div><div class="t m0 x1 h2 y43 ff1 fs0 fc0 sc0 ls0 ws0"> data, and must be acknowledged by an acknowledgment packet before the </div><div class="t m0 x1 h2 y44 ff1 fs0 fc0 sc0 ls0 ws0"> next packet can be sent. A data packet of less than 512 bytes </div><div class="t m0 x1 h2 y45 ff1 fs0 fc0 sc0 ls0 ws0"> signals termination of a transfer. If a packet gets lost in the </div><div class="t m0 x1 h2 y46 ff1 fs0 fc0 sc0 ls0 ws0"> network, the intended recipient will timeout and may retransmit his </div><div class="t m0 x1 h2 y47 ff1 fs0 fc0 sc0 ls0 ws0"> last packet (which may be data or an acknowledgment), thus causing </div><div class="t m0 x1 h2 y48 ff1 fs0 fc0 sc0 ls0 ws0"> the sender of the lost packet to retransmit that lost packet. The </div><div class="t m0 x1 h2 y49 ff1 fs0 fc0 sc0 ls0 ws0"> sender has to keep just one packet on hand for retransmission, since </div><div class="t m0 x1 h2 y4a ff1 fs0 fc0 sc0 ls0 ws0"> the lock step acknowledgment guarantees that all older packets have </div><div class="t m0 x1 h2 y4b ff1 fs0 fc0 sc0 ls0 ws0"> been received. Notice that both machines involved in a transfer are </div><div class="t m0 x1 h2 y4c ff1 fs0 fc0 sc0 ls0 ws0"> considered senders and receivers. One sends data and receives </div><div class="t m0 x1 h2 y4d ff1 fs0 fc0 sc0 ls0 ws0"> acknowledgments, the other sends acknowledgments and receives data. </div><div class="t m0 x1 h2 y4e ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y4f ff1 fs0 fc0 sc0 ls0 ws0"> Most errors cause termination of the connection. An error is </div><div class="t m0 x1 h2 y50 ff1 fs0 fc0 sc0 ls0 ws0"> signalled by sending an error packet. This packet is not </div><div class="t m0 x1 h2 y51 ff1 fs0 fc0 sc0 ls0 ws0"> acknowledged, and not retransmitted (i.e., a TFTP server or user may </div><div class="t m0 x1 h2 y52 ff1 fs0 fc0 sc0 ls0 ws0"> terminate after sending an error message), so the other end of the </div><div class="t m0 x1 h2 y53 ff1 fs0 fc0 sc0 ls0 ws0"> connection may not get it. Therefore timeouts are used to detect </div><div class="t m0 x1 h2 y54 ff1 fs0 fc0 sc0 ls0 ws0"> such a termination when the error packet has been lost. Errors are </div><div class="t m0 x1 h2 y55 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y56 ff1 fs0 fc0 sc0 ls0 ws0">Sollins [Page 2] </div></div><div class="pi" data-data='{"ctm":[1.346230,0.000000,0.000000,1.346230,0.000000,0.000000]}'></div></div>
<div id="pf3" class="pf w0 h0" data-page-no="3"><div class="pc pc3 w0 h0"><img class="bi x0 y0 w1 h1" alt="" src="https://csdnimg.cn/release/download_crawler_static/2529827/bg3.jpg"><div class="t m0 x1 h2 y1 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y2 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y3 ff1 fs0 fc0 sc0 ls0 ws0">RFC 1350 TFTP Revision 2 July 1992 </div><div class="t m0 x1 h2 y4 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y5 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y6 ff1 fs0 fc0 sc0 ls0 ws0"> caused by three types of events: not being able to satisfy the </div><div class="t m0 x1 h2 y7 ff1 fs0 fc0 sc0 ls0 ws0"> request (e.g., file not found, access violation, or no such user), </div><div class="t m0 x1 h2 y8 ff1 fs0 fc0 sc0 ls0 ws0"> receiving a packet which cannot be explained by a delay or </div><div class="t m0 x1 h2 y9 ff1 fs0 fc0 sc0 ls0 ws0"> duplication in the network (e.g., an incorrectly formed packet), and </div><div class="t m0 x1 h2 ya ff1 fs0 fc0 sc0 ls0 ws0"> losing access to a necessary resource (e.g., disk full or access </div><div class="t m0 x1 h2 yb ff1 fs0 fc0 sc0 ls0 ws0"> denied during a transfer). </div><div class="t m0 x1 h2 yc ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 yd ff1 fs0 fc0 sc0 ls0 ws0"> TFTP recognizes only one error condition that does not cause<span class="ls1"> </span></div><div class="t m0 x1 h2 ye ff1 fs0 fc0 sc0 ls0 ws0"> termination, the source port of a received packet being incorrect. </div><div class="t m0 x1 h2 y2d ff1 fs0 fc0 sc0 ls0 ws0"> In this case, an error packet is sent to the originating host. </div><div class="t m0 x1 h2 y2e ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y2f ff1 fs0 fc0 sc0 ls0 ws0"> This protocol is very restrictive, in order to simplify </div><div class="t m0 x1 h2 y30 ff1 fs0 fc0 sc0 ls0 ws0"> implementation. For example, the fixed length blocks make allocation </div><div class="t m0 x1 h2 y31 ff1 fs0 fc0 sc0 ls0 ws0"> straight forward, and the lock step acknowledgement provides flow </div><div class="t m0 x1 h2 y32 ff1 fs0 fc0 sc0 ls0 ws0"> control and eliminates the need to reorder incoming data packets. </div><div class="t m0 x1 h2 y33 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y34 ff1 fs0 fc0 sc0 ls0 ws0">3. Relation to other Protocols </div><div class="t m0 x1 h2 y35 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y36 ff1 fs0 fc0 sc0 ls0 ws0"> As mentioned TFTP is designed to be implemented on top of the </div><div class="t m0 x1 h2 y37 ff1 fs0 fc0 sc0 ls0 ws0"> Datagram protocol (UDP). Since Datagram is implemented on the </div><div class="t m0 x1 h2 y38 ff1 fs0 fc0 sc0 ls0 ws0"> Internet protocol, packets will have an Internet header, a Datagram </div><div class="t m0 x1 h2 y39 ff1 fs0 fc0 sc0 ls0 ws0"> header, and a TFTP header. Additionally, the packets may have a </div><div class="t m0 x1 h2 y3a ff1 fs0 fc0 sc0 ls0 ws0"> header (LNI, ARPA header, etc.) to allow them through the local </div><div class="t m0 x1 h2 y3b ff1 fs0 fc0 sc0 ls0 ws0"> transport medium. As shown in Figure 3-1, the order of the contents </div><div class="t m0 x1 h2 y3c ff1 fs0 fc0 sc0 ls0 ws0"> of a packet will be: local medium header, if used, Internet header, </div><div class="t m0 x1 h2 y3d ff1 fs0 fc0 sc0 ls0 ws0"> Datagram header, TFTP header, followed by the remainder of the TFTP </div><div class="t m0 x1 h2 y3e ff1 fs0 fc0 sc0 ls0 ws0"> packet. (This may or may not be data depending on the type of packet </div><div class="t m0 x1 h2 y3f ff1 fs0 fc0 sc0 ls0 ws0"> as specified in the TFTP header.) TFTP does not specify any of the </div><div class="t m0 x1 h2 y40 ff1 fs0 fc0 sc0 ls0 ws0"> values in the Internet header. On the other hand, the source and </div><div class="t m0 x1 h2 y41 ff1 fs0 fc0 sc0 ls0 ws0"> destination port fields of the Datagram header (its format is given </div><div class="t m0 x1 h2 y42 ff1 fs0 fc0 sc0 ls0 ws0"> in the appendix) are used by TFTP and the length field reflects the </div><div class="t m0 x1 h2 y43 ff1 fs0 fc0 sc0 ls0 ws0"> size of the TFTP packet. The transfer identifiers (TID's) used by </div><div class="t m0 x1 h2 y44 ff1 fs0 fc0 sc0 ls0 ws0"> TFTP are passed to the Datagram layer to be used as ports; therefore </div><div class="t m0 x1 h2 y45 ff1 fs0 fc0 sc0 ls0 ws0"> they must be between 0 and 65,535. The initialization of TID's is </div><div class="t m0 x1 h2 y46 ff1 fs0 fc0 sc0 ls0 ws0"> discussed in the section on initial connection protocol. </div><div class="t m0 x1 h2 y47 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y48 ff1 fs0 fc0 sc0 ls0 ws0"> The TFTP header consists of a 2 byte opcode field which indicates </div><div class="t m0 x1 h2 y49 ff1 fs0 fc0 sc0 ls0 ws0"> the packet's type (e.g., DATA, ERROR, etc.) These opcodes and the </div><div class="t m0 x1 h2 y4a ff1 fs0 fc0 sc0 ls0 ws0"> formats of the various types of packets are discussed further in the </div><div class="t m0 x1 h2 y4b ff1 fs0 fc0 sc0 ls0 ws0"> section on TFTP packets. </div><div class="t m0 x1 h2 y4c ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y4d ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y4e ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y4f ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y50 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y51 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y52 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y53 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y54 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y55 ff1 fs0 fc0 sc0 ls0 ws0">Sollins [Page 3] </div><div class="t m0 x1 h2 y56 ff1 fs0 fc0 sc0 ls1 ws0"> </div></div><div class="pi" data-data='{"ctm":[1.346230,0.000000,0.000000,1.346230,0.000000,0.000000]}'></div></div>
<div id="pf4" class="pf w0 h0" data-page-no="4"><div class="pc pc4 w0 h0"><img class="bi x0 y0 w1 h1" alt="" src="https://csdnimg.cn/release/download_crawler_static/2529827/bg4.jpg"><div class="t m0 x1 h2 y1 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y2 ff1 fs0 fc0 sc0 ls0 ws0">RFC 1350 TFTP Revision 2 July 1992 </div><div class="t m0 x1 h2 y3 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y4 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y5 ff1 fs0 fc0 sc0 ls0 ws0"> --------------------------------------------------- </div><div class="t m0 x1 h2 y6 ff1 fs0 fc0 sc0 ls0 ws0"> | Local Medium | Internet | Datagram | TFTP | </div><div class="t m0 x1 h2 y7 ff1 fs0 fc0 sc0 ls0 ws0"> --------------------------------------------------- </div><div class="t m0 x1 h2 y8 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y9 ff1 fs0 fc0 sc0 ls0 ws0"> Figure 3-1: Order of Headers </div><div class="t m0 x1 h2 ya ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 yb ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 yc ff1 fs0 fc0 sc0 ls0 ws0">4. Initial Connection Protocol </div><div class="t m0 x1 h2 yd ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 ye ff1 fs0 fc0 sc0 ls0 ws0"> A transfer is established by sending a request (WRQ to write onto a </div><div class="t m0 x1 h2 y2d ff1 fs0 fc0 sc0 ls0 ws0"> foreign file system, or RRQ to read from it), and receiving a </div><div class="t m0 x1 h2 y2e ff1 fs0 fc0 sc0 ls0 ws0"> positive reply, an acknowledgment packet for write, or the first data </div><div class="t m0 x1 h2 y2f ff1 fs0 fc0 sc0 ls0 ws0"> packet for read. In general an acknowledgment packet will contain </div><div class="t m0 x1 h2 y30 ff1 fs0 fc0 sc0 ls0 ws0"> the block number of the data packet being acknowledged. Each data </div><div class="t m0 x1 h2 y31 ff1 fs0 fc0 sc0 ls0 ws0"> packet has associated with it a block number; block numbers are </div><div class="t m0 x1 h2 y32 ff1 fs0 fc0 sc0 ls0 ws0"> consecutive and begin with one. Since the positive response to a </div><div class="t m0 x1 h2 y33 ff1 fs0 fc0 sc0 ls0 ws0"> write request is an acknowledgment packet, in this special case the </div><div class="t m0 x1 h2 y34 ff1 fs0 fc0 sc0 ls0 ws0"> block number will be zero. (Normally, since an acknowledgment packet </div><div class="t m0 x1 h2 y35 ff1 fs0 fc0 sc0 ls0 ws0"> is acknowledging a data packet, the acknowledgment packet will </div><div class="t m0 x1 h2 y36 ff1 fs0 fc0 sc0 ls0 ws0"> contain the block number of the data packet being acknowledged.) If </div><div class="t m0 x1 h2 y37 ff1 fs0 fc0 sc0 ls0 ws0"> the reply is an error packet, then the request has been denied. </div><div class="t m0 x1 h2 y38 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y39 ff1 fs0 fc0 sc0 ls0 ws0"> In order to create a connection, each end of the connection chooses a </div><div class="t m0 x1 h2 y3a ff1 fs0 fc0 sc0 ls0 ws0"> TID for itself, to be used for the duration of that connection. The </div><div class="t m0 x1 h2 y3b ff1 fs0 fc0 sc0 ls0 ws0"> TID's chosen for a connection should be randomly chosen, so that the </div><div class="t m0 x1 h2 y3c ff1 fs0 fc0 sc0 ls0 ws0"> probability that the same number is chosen twice in immediate </div><div class="t m0 x1 h2 y3d ff1 fs0 fc0 sc0 ls0 ws0"> succession is very low. Every packet has associated with it the two </div><div class="t m0 x1 h2 y3e ff1 fs0 fc0 sc0 ls0 ws0"> TID's of the ends of the connection, the source TID and the </div><div class="t m0 x1 h2 y3f ff1 fs0 fc0 sc0 ls0 ws0"> destination TID. These TID's are handed to the supporting UDP (or </div><div class="t m0 x1 h2 y40 ff1 fs0 fc0 sc0 ls0 ws0"> other datagram protocol) as the source and destination ports. A </div><div class="t m0 x1 h2 y41 ff1 fs0 fc0 sc0 ls0 ws0"> requesting host chooses its source TID as described above, and sends </div><div class="t m0 x1 h2 y42 ff1 fs0 fc0 sc0 ls0 ws0"> its initial request to the known TID 69 decimal (105 octal) on the </div><div class="t m0 x1 h2 y43 ff1 fs0 fc0 sc0 ls0 ws0"> serving host. The response to the request, under normal operation, </div><div class="t m0 x1 h2 y44 ff1 fs0 fc0 sc0 ls0 ws0"> uses a TID chosen by the server as its source TID and the TID chosen </div><div class="t m0 x1 h2 y45 ff1 fs0 fc0 sc0 ls0 ws0"> for the previous message by the requestor as its destination TID. </div><div class="t m0 x1 h2 y46 ff1 fs0 fc0 sc0 ls0 ws0"> The two chosen TID's are then used for the remainder of the transfer. </div><div class="t m0 x1 h2 y47 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y48 ff1 fs0 fc0 sc0 ls0 ws0"> As an example, the following shows the steps used to establish a </div><div class="t m0 x1 h2 y49 ff1 fs0 fc0 sc0 ls0 ws0"> connection to write a file. Note that WRQ, ACK, and DATA are the </div><div class="t m0 x1 h2 y4a ff1 fs0 fc0 sc0 ls0 ws0"> names of the write request, acknowledgment, and data types of packets </div><div class="t m0 x1 h2 y4b ff1 fs0 fc0 sc0 ls0 ws0"> respectively. The appendix contains a similar example for reading a </div><div class="t m0 x1 h2 y4c ff1 fs0 fc0 sc0 ls0 ws0"> file. </div><div class="t m0 x1 h2 y4d ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y4e ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y4f ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y50 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y51 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y52 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y53 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y54 ff1 fs0 fc0 sc0 ls1 ws0"> </div><div class="t m0 x1 h2 y55 ff1 fs0 fc0 sc0 ls0 ws0">Sollins [Page 4] </div><div class="t m0 x1 h2 y56 ff1 fs0 fc0 sc0 ls1 ws0"> </div></div><div class="pi" data-data='{"ctm":[1.346230,0.000000,0.000000,1.346230,0.000000,0.000000]}'></div></div>
