Trivial File Transfer Protocol (TFTP)
From DrugPedia: A Wikipedia for Drug discovery
(Difference between revisions)
(→Some details of TFTP) |
|||
| (13 intermediate revisions not shown.) | |||
| Line 10: | Line 10: | ||
| - | == | + | ==Technical information== |
| - | == Some details of TFTP == | + | ===Some details of TFTP=== |
| + | [[Image:250px-Tftp-wrq.svg.png|frame|Host A requests to write]] | ||
| + | [[Image:412px-Tftp-ack0.svg.png|thumb|250px| Server S acknowledges request]] | ||
| + | [[Image:412px-Tftp-dat1-up.svg.png|thumb|250px|Host A sends numbered data packets]] | ||
| + | [[Image:412px-Tftp-rrq.svg.png|thumb|250px|Host A requests to read]] | ||
| + | [[Image:412px-Tftp-dat1-dwn.svg.png|thumb|250px|Server S sends data packet 1]] | ||
| + | [[Image:412px-Tftp-ack1.svg.png|thumb|250px|Host A acknowledges data packet 1]] | ||
* It uses UDP port 69 as its transport protocol (unlike FTP which uses TCP port 21). | * It uses UDP port 69 as its transport protocol (unlike FTP which uses TCP port 21). | ||
| - | * It cannot list directory contents. | + | * It cannot list directory contents. |
* It has no authentication or encryption mechanisms. | * It has no authentication or encryption mechanisms. | ||
| - | + | * It is used to read files from, or write files to, a remote server. | |
| - | * It is used to read files from, or write files to, a remote server. | + | * It supports three different transfer modes, "netascii", "octet" and "mail", with the first two corresponding to the "ASCII" and "image"(binary) modes of the FTP protocol; the third is obsoleted by RFC1350. |
| - | * It supports three different transfer modes, "netascii", "octet" and "mail", with the first two corresponding to the "ASCII" and "image" (binary) modes of the FTP protocol; the third is obsoleted by RFC1350. | + | * The original protocol has a file size limit of 32 MB, although this was extended when RFC 2347 introduced option negotiation, which was used in RFC 2348 to introduce block-size negotiation in 1998 (allowing a maximum of 4 GB and potentially higher throughput).If the server and client support block number wraparound, file size is essentially unlimited. |
| - | * The original protocol has a file size limit of 32 MB, although this was extended when RFC 2347 introduced option negotiation, which was used in RFC 2348 to introduce block-size negotiation in 1998 (allowing a maximum of 4 GB and potentially higher throughput). If the server and client support block number wraparound, file size is essentially unlimited. | + | |
* Since TFTP utilizes UDP, it has to supply its own transport and session support. Each file transferred via TFTP constitutes an independent exchange. That transfer is performed in lock-step, with only one packet (either a block of data, or an 'acknowledgement') ever in flight on the network at any time. Due to this lack of windowing, TFTP provides low throughput over high latency links. | * Since TFTP utilizes UDP, it has to supply its own transport and session support. Each file transferred via TFTP constitutes an independent exchange. That transfer is performed in lock-step, with only one packet (either a block of data, or an 'acknowledgement') ever in flight on the network at any time. Due to this lack of windowing, TFTP provides low throughput over high latency links. | ||
* Due to the lack of security, it is dangerous over the open Internet. Thus, TFTP is generally only used on private, local networks. | * Due to the lack of security, it is dangerous over the open Internet. Thus, TFTP is generally only used on private, local networks. | ||
| + | |||
| + | ===Details of a TFTP session=== | ||
| + | |||
| + | * The initiating host A sends an RRQ (read request) or WRQ (write request) packet to host B at the well-known port number 69, containing the filename and transfer mode. | ||
| + | * B replies with an ACK (acknowledgement) packet to WRQ and directly with a DATA packet to RRQ. Packet is sent from a freshly allocated ephemeral port, and all future packets to host B should be to this port. | ||
| + | * The source host sends numbered DATA packets to the destination host, all but the last containing a full-sized block of data. The destination host replies with numbered ACK packets for all DATA packets. | ||
| + | * The final DATA packet must contain less than a full-sized block of data to signal that it is the last. If the size of the transferred file is an exact multiple of the block-size, the source sends a final DATA packet containing 0 bytes of data | ||
Current revision
Trivial File Transfer Protocol (TFTP) is a very simple file transfer protocol, with the functionality of a very basic form of FTP; it was first defined in 1980.
Since it is so simple, it is easy to implement in a very small amount of memory — an important consideration at that time. TFTP was therefore useful for booting computers such as routers which did not have any data storage devices. It is still used to transfer small files between hosts on a network, such as when a remote X Window System terminal or any other thin client boots from a network host or server.
TFTP is based in part on the earlier protocol EFTP, which was part of the PUP protocol suite. In the early days of work on the TCP/IP protocol suite, TFTP was often the first protocol implemented on a new host type, because it was so simple.
The original versions of TFTP, prior to RFC 1350, displayed a particularly bad protocol flaw, which was named Sorcerer's Apprentice Syndrome (after the Sorcerer's Apprentice segment of Fantasia) when it was discovered.
TFTP appeared first as part of 4.3 BSD. It is included with Mac OS X through at least version 10.5.
[edit] Technical information
[edit] Some details of TFTP
Host A requests to write
| Error creating thumbnail: convert: unable to open image `/usr1/webserver/cgidocs/drugpedia/images/412px-Tftp-ack0.svg.png': No such file or directory @ blob.c/OpenBlob/2480. convert: unable to open file `/usr1/webserver/cgidocs/drugpedia/images/412px-Tftp-ack0.svg.png' @ png.c/ReadPNGImage/2889. convert: missing an image filename `/usr1/webserver/cgidocs/drugpedia/images/thumb/412px-Tftp-ack0.svg.png/250px-412px-Tftp-ack0.svg.png' @ convert.c/ConvertImageCommand/2800. |
| Error creating thumbnail: convert: unable to open image `/usr1/webserver/cgidocs/drugpedia/images/412px-Tftp-dat1-up.svg.png': No such file or directory @ blob.c/OpenBlob/2480. convert: unable to open file `/usr1/webserver/cgidocs/drugpedia/images/412px-Tftp-dat1-up.svg.png' @ png.c/ReadPNGImage/2889. convert: missing an image filename `/usr1/webserver/cgidocs/drugpedia/images/thumb/412px-Tftp-dat1-up.svg.png/250px-412px-Tftp-dat1-up.svg.png' @ convert.c/ConvertImageCommand/2800. |
| Error creating thumbnail: convert: unable to open image `/usr1/webserver/cgidocs/drugpedia/images/412px-Tftp-rrq.svg.png': No such file or directory @ blob.c/OpenBlob/2480. convert: unable to open file `/usr1/webserver/cgidocs/drugpedia/images/412px-Tftp-rrq.svg.png' @ png.c/ReadPNGImage/2889. convert: missing an image filename `/usr1/webserver/cgidocs/drugpedia/images/thumb/412px-Tftp-rrq.svg.png/250px-412px-Tftp-rrq.svg.png' @ convert.c/ConvertImageCommand/2800. |
| Error creating thumbnail: convert: unable to open image `/usr1/webserver/cgidocs/drugpedia/images/412px-Tftp-dat1-dwn.svg.png': No such file or directory @ blob.c/OpenBlob/2480. convert: unable to open file `/usr1/webserver/cgidocs/drugpedia/images/412px-Tftp-dat1-dwn.svg.png' @ png.c/ReadPNGImage/2889. convert: missing an image filename `/usr1/webserver/cgidocs/drugpedia/images/thumb/412px-Tftp-dat1-dwn.svg.png/250px-412px-Tftp-dat1-dwn.svg.png' @ convert.c/ConvertImageCommand/2800. |
| Error creating thumbnail: convert: unable to open image `/usr1/webserver/cgidocs/drugpedia/images/412px-Tftp-ack1.svg.png': No such file or directory @ blob.c/OpenBlob/2480. convert: unable to open file `/usr1/webserver/cgidocs/drugpedia/images/412px-Tftp-ack1.svg.png' @ png.c/ReadPNGImage/2889. convert: missing an image filename `/usr1/webserver/cgidocs/drugpedia/images/thumb/412px-Tftp-ack1.svg.png/250px-412px-Tftp-ack1.svg.png' @ convert.c/ConvertImageCommand/2800. |
- It uses UDP port 69 as its transport protocol (unlike FTP which uses TCP port 21).
- It cannot list directory contents.
- It has no authentication or encryption mechanisms.
- It is used to read files from, or write files to, a remote server.
- It supports three different transfer modes, "netascii", "octet" and "mail", with the first two corresponding to the "ASCII" and "image"(binary) modes of the FTP protocol; the third is obsoleted by RFC1350.
- The original protocol has a file size limit of 32 MB, although this was extended when RFC 2347 introduced option negotiation, which was used in RFC 2348 to introduce block-size negotiation in 1998 (allowing a maximum of 4 GB and potentially higher throughput).If the server and client support block number wraparound, file size is essentially unlimited.
- Since TFTP utilizes UDP, it has to supply its own transport and session support. Each file transferred via TFTP constitutes an independent exchange. That transfer is performed in lock-step, with only one packet (either a block of data, or an 'acknowledgement') ever in flight on the network at any time. Due to this lack of windowing, TFTP provides low throughput over high latency links.
- Due to the lack of security, it is dangerous over the open Internet. Thus, TFTP is generally only used on private, local networks.
[edit] Details of a TFTP session
- The initiating host A sends an RRQ (read request) or WRQ (write request) packet to host B at the well-known port number 69, containing the filename and transfer mode.
- B replies with an ACK (acknowledgement) packet to WRQ and directly with a DATA packet to RRQ. Packet is sent from a freshly allocated ephemeral port, and all future packets to host B should be to this port.
- The source host sends numbered DATA packets to the destination host, all but the last containing a full-sized block of data. The destination host replies with numbered ACK packets for all DATA packets.
- The final DATA packet must contain less than a full-sized block of data to signal that it is the last. If the size of the transferred file is an exact multiple of the block-size, the source sends a final DATA packet containing 0 bytes of data
