417.htm

pcb设计资料初学者难得的入门资料包含工厂制作过程

            ------------------------------------------------ <br>
                       Figure 5-1: RRQ/WRQ packet <br>
   RRQ and WRQ packets (opcodes 1 and 2 respectively) have the format <br>
   shown in Figure 5-1.  The file name is a sequence of bytes in <br>
   netascii terminated by a zero byte.  The mode field contains the <br>
   string "netascii", "octet", or "mail" (or any combination of upper <br>
   and lower case, such as "NETASCII", NetAscii", etc.) in netascii <br>
   indicating the three modes defined in the protocol.  A host which <br>
   receives netascii mode data must translate the data to its own <br>
   format.  Octet mode is used to transfer a file that is in the 8-bit <br>
   format of the machine from which the file is being transferred.  It <br>

   is assumed that each type of machine has a single 8-bit format that <br>
   is more common, and that that format is chosen.  For example, on a <br>
   DEC-20, a 36 bit machine, this is four 8-bit bytes to a word with <br>
   four bits of breakage.  If a host receives a octet file and then <br>
   returns it, the returned file must be identical to the original. <br>
   Mail mode uses the name of a mail recipient in place of a file and <br>
   must begin with a WRQ.  Otherwise it is identical to netascii mode. <br>
   The mail recipient string should be of the form "username" or <br>
   "username@hostname".  If the second form is used, it allows the <br>
   option of mail forwarding by a relay computer. <br>
   The discussion above assumes that both the sender and recipient are <br>
   operating in the same mode, but there is no reason that this has to <br>
   be the case.  For example, one might build a storage server.  There <br>
   is no reason that such a machine needs to translate netascii into its <br>
   own form of text.  Rather, the sender might send files in netascii, <br>
   but the storage server might simply store them without translation in <br>
   8-bit format.  Another such situation is a problem that currently <br>
   exists on DEC-20 systems.  Neither netascii nor octet accesses all <br>
   the bits in a word.  One might create a special mode for such a <br>
   machine which read all the bits in a word, but in which the receiver <br>
   stored the information in 8-bit format.  When such a file is <br>
   retrieved from the storage site, it must be restored to its original <br>

   form to be useful, so the reverse mode must also be implemented.  The <br>
   user site will have to remember some information to achieve this.  In <br>
   both of these examples, the request packets would specify octet mode <br>
   to the foreign host, but the local host would be in some other mode. <br>
   No such machine or application specific modes have been specified in <br>
   TFTP, but one would be compatible with this specification. <br>
   It is also possible to define other modes for cooperating pairs of <br>
Sollins                                                         [Page 6] <br>
  <br>
RFC 1350                    TFTP Revision 2                    July 1992 <br>
   hosts, although this must be done with care.  There is no requirement <br>
   that any other hosts implement these.  There is no central authority <br>
   that will define these modes or assign them names. <br>
                   2 bytes     2 bytes      n bytes <br>
                   ---------------------------------- <br>
                  | Opcode |   Block #  |   Data     | <br>
                   ---------------------------------- <br>
                        Figure 5-2: DATA packet <br>
   Data is actually transferred in DATA packets depicted in Figure 5-2. <br>
   DATA packets (opcode = 3) have a block number and data field.  The <br>
   block numbers on data packets begin with one and increase by one for <br>
   each new block of data.  This restriction allows the program to use a <br>

   single number to discriminate between new packets and duplicates. <br>
   The data field is from zero to 512 bytes long.  If it is 512 bytes <br>
   long, the block is not the last block of data; if it is from zero to <br>
   511 bytes long, it signals the end of the transfer.  (See the section <br>
   on Normal Termination for details.) <br>
   All  packets other than duplicate ACK's and those used for <br>
   termination are acknowledged unless a timeout occurs [4].  Sending a <br>
   DATA packet is an acknowledgment for the first ACK packet of the <br>
   previous DATA packet. The WRQ and DATA packets are acknowledged by <br>
   ACK or ERROR packets, while RRQ <br>
                         2 bytes     2 bytes <br>
                         --------------------- <br>
                        | Opcode |   Block #  | <br>
                         --------------------- <br>
                         Figure 5-3: ACK packet <br>
   and ACK packets are acknowledged by  DATA  or ERROR packets.  Figure <br>
   5-3 depicts an ACK packet; the opcode is 4.  The  block  number  in <br>
   an  ACK echoes the block number of the DATA packet being <br>
   acknowledged.  A WRQ is acknowledged with an ACK packet having a <br>
   block number of zero. <br>
Sollins                                                         [Page 7] <br>
  <br>
  <br>
RFC 1350                    TFTP Revision 2                    July 1992 <br>
               2 bytes     2 bytes      string    1 byte <br>
               ----------------------------------------- <br>
              | Opcode |  ErrorCode |   ErrMsg   |   0  | <br>
               ----------------------------------------- <br>
                        Figure 5-4: ERROR packet <br>
   An ERROR packet (opcode 5) takes the form depicted in Figure 5-4.  An <br>
   ERROR packet can be the acknowledgment of any other type of packet. <br>
   The error code is an integer indicating the nature of the error.  A <br>
   table of values and meanings is given in the appendix.  (Note that <br>
   several error codes have been added to this version of this <br>
   document.) The error message is intended for human consumption, and <br>
   should be in netascii.  Like all other strings, it is terminated with <br>
   a zero byte. <br>
6. Normal Termination <br>
   The end of a transfer is marked by a DATA packet that contains <br>
   between 0 and 511 bytes of data (i.e., Datagram length < 516).  This <br>
   packet is acknowledged by an ACK packet like all other DATA packets. <br>
   The host acknowledging the final DATA packet may terminate its side <br>
   of the connection on sending the final ACK.  On the other hand, <br>
   dallying is encouraged.  This means that the host sending the final <br>
   ACK will wait for a while before terminating in order to retransmit <br>

   the final ACK if it has been lost.  The acknowledger will know that <br>
   the ACK has been lost if it receives the final DATA packet again. <br>
   The host sending the last DATA must retransmit it until the packet is <br>
   acknowledged or the sending host times out.  If the response is an <br>
   ACK, the transmission was completed successfully.  If the sender of <br>
   the data times out and is not prepared to retransmit any more, the <br>
   transfer may still have been completed successfully, after which the <br>
   acknowledger or network may have experienced a problem.  It is also <br>
   possible in this case that the transfer was unsuccessful.  In any <br>
   case, the connection has been closed. <br>
7. Premature Termination <br>
   If a request can not be granted, or some error occurs during the <br>
   transfer, then an ERROR packet (opcode 5) is sent.  This is only a <br>
   courtesy since it will not be retransmitted or acknowledged, so it <br>
   may never be received.  Timeouts must also be used to detect errors. <br>
Sollins                                                         [Page 8] <br>
  <br>
RFC 1350                    TFTP Revision 2                    July 1992 <br>
I. Appendix <br>
Order of Headers <br>
                                                  2 bytes <br>
    ---------------------------------------------------------- <br>

   |  Local Medium  |  Internet  |  Datagram  |  TFTP Opcode  | <br>
    ---------------------------------------------------------- <br>
TFTP Formats <br>
   Type   Op #     Format without header <br>
          2 bytes    string   1 byte     string   1 byte <br>
          ----------------------------------------------- <br>
   RRQ/  | 01/02 |  Filename  |   0  |    Mode    |   0  | <br>
   WRQ    ----------------------------------------------- <br>
          2 bytes    2 bytes       n bytes <br>
          --------------------------------- <br>
   DATA  | 03    |   Block #  |    Data    | <br>
          --------------------------------- <br>
          2 bytes    2 bytes <br>
          ------------------- <br>
   ACK   | 04    |   Block #  | <br>
          -------------------- <br>
          2 bytes  2 bytes        string    1 byte <br>
          ---------------------------------------- <br>
   ERROR | 05    |  ErrorCode |   ErrMsg   |   0  | <br>
          ---------------------------------------- <br>
Initial Connection Protocol for reading a file <br>
   1. Host  A  sends  a  "RRQ"  to  host  B  with  source= A's TID, <br>

      destination= 69. <br>
   2. Host B sends a "DATA" (with block number= 1) to host  A  with <br>
      source= B's TID, destination= A's TID. <br>
Sollins                                                         [Page 9] <br>
  <br>
RFC 1350                    TFTP Revision 2                    July 1992 <br>
Error Codes <br>
   Value     Meaning <br>
   0         Not defined, see error message (if any). <br>
   1         File not found. <br>
   2         Access violation. <br>
   3         Disk full or allocation exceeded. <br>
   4         Illegal TFTP operation. <br>
   5         Unknown transfer ID. <br>
   6         File already exists. <br>
   7         No such user. <br>
Internet User Datagram Header [2] <br>
   (This has been included only for convenience.  TFTP need not be <br>
   implemented on top of the Internet User Datagram Protocol.) <br>
     Format <br>
    0                   1                   2                   3 <br>
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 <br>

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
   |          Source Port          |       Destination Port        | <br>
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
   |            Length             |           Checksum            | <br>
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <br>
   Values of Fields <br>
   Source Port     Picked by originator of packet. <br>
   Dest. Port      Picked by destination machine (69 for RRQ or WRQ). <br>
   Length          Number of bytes in UDP packet, including UDP header. <br>
   Checksum        Reference 2 describes rules for computing checksum. <br>
                   (The implementor of this should be sure that the <br>
                   correct algorithm is used here.) <br>
                   Field contains zero if unused. <br>
   Note: TFTP passes transfer identifiers (TID's) to the Internet User <br>
   Datagram protocol to be used as the source and destination ports. <br>
Sollins                                                        [Page 10] <br>
  <br>
RFC 1350                    TFTP Revision 2                    July 1992 <br>
References <br>
   [1]  USA Standard Code for Information Interchange, USASI X3.4-1968. <br>
   [2]  Postel, J., "User Datagram  Protocol," RFC 768, USC/Information <br>
        Sciences Institute, 28 August 1980. <br>

   [3]  Postel, J., "Telnet Protocol Specification," RFC 764, <br>
        USC/Information Sciences Institute, June, 1980. <br>
   [4]  Braden, R., Editor, "Requirements for Internet Hosts -- <br>
        Application and Support", RFC 1123, USC/Information Sciences <br>
        Institute, October 1989. <br>
Security Considerations <br>
   Since TFTP includes no login or access control mechanisms, care must <br>
   be taken in the rights granted to a TFTP server process so as not to <br>
   violate the security of the server hosts file system.  TFTP is often <br>
   installed with controls such that only files that have public read <br>
   access are available via TFTP and writing files via TFTP is <br>
   disallowed. <br>
Author's Address <br>
   Karen R. Sollins <br>
   Massachusetts Institute of Technology <br>
   Laboratory for Computer Science <br>
   545 Technology Square <br>
   Cambridge, MA 02139-1986 <br>
   Phone: [phone] <br>
   EMail: [e-mail] <br>
Sollins                                                        [Page 11] <br>
  <br>

  <br>
  <br>
-- <br>
指点江山，激扬文字，粪土当年万户侯。 <br>
  <br>
  <br>
※ 来源:·BBS 水木清华站 smth.org·[FROM: 166.111.161.69] <br>
</small><hr>
<p align="center">[<a href="嵌入式系统.htm">回到开始</a>][<a href="398.htm">上一层</a>][<a href="418.htm">下一篇</a>]
<p align="center"><a href="http://cterm.163.net">欢迎访问Cterm主页</a></p>
</table>
</body>
</html>