?? 00000015.htm
字號:
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 /> ------------------------------------------------ <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 /> "<a href="mailto:username@hostname".">username@hostname".</a> 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 />
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -