Some time ago I heard about TFTP - something I've never encountered before. TFTP is an
acronym for Trivial File Transfer Protocol. Yes, like FTP, just Trivial. TFTP is a much
watered down version of FTP - its only command is to transfer a file from a place to a
place - no directory listing, deleting, renaming, user authentication. What is it useful
for, one may wonder. Well, not every computer is a PC. In recent years more and more small
embedded devices are becoming networked, and one of the best forms of networking is TCP /
UDP / IP - the same set of protocols the Internet works on.
TFTP works on top of UDP, as
opposed to FTP which works on TCP. UDP is a far simpler protocol than TCP, since it is a
"send and forget" concept, without ensuring the correct arrival of data, in order, like TCP
does. As a result, it is much easier to implement which leads to an implementation with a
smaller footprint, and this is important for embedded devices.
TFTP itself is also much
simpler than FTP. It ensures the correct transfer of data by employing a simple
stop and wait
protocol on top of UDP. I assume that it also makes it slower than FTP on non-congested
networks, since FTP's reliability is achieved on the TCP level which works in
selective repeat.
However, simplicity is often more important than performance, especially for embedded
devices with small amounts of ROM.
So TFTP is perfect for embedded devices to transfer data
to and from each other (and PCs) in a reliable, quick way (UDP / IP on Ethernet is far
faster than serial RS232 / RS485 communication, the most common interconnection method of
embedded devices).
The research into TFTP led me through a few interesting sources of
information, on Wikipedia, HowStuffWorks and RFCs.
RFC 1180 is especially helpful - it's a
tutorial written in a very readable style that explains the basics of IP, ARP, routing
tables and TCP / UDP.
RFC 1123 is a thorough collection of
all Internet related protocols with cross references to other relevant RFCs.
The TCP / UDP
/ IP network stack is one of the nicest examples of sound engineering, and IMHO it is
beneficial to get at least a superficial understanding of how these things work under the
hood.
Does anyone know of a way to increase TFTP transfer
speeds over the WAN? We're in the process of distributing
new IOS and ASA releases and transferring images using TFTP
over the WAN is dreadfully slow. It works great on the LAN
of course with gigabit speeds but there's no scalable way of
doing it with numerous remote locations.
As you may be aware, the way TFTP works is that it
transfers a single data packet containing one block of data,
and that packet must be acknowledged before the next packet
can be sent. With this in mind there are really only two
ways to increase TFTP performance.
1. Increase the TFTP blocksize
The default TFTP blocksize is 512-bytes, but if your
client and server both support
RFC 2348 TFTP Blocksize Option then the blocksize can be
increased to approximately 1450-bytes. There are
measurements in the aforementioned RFC that show a 2.8x
performance improvement when using 1428-byte blocks compared
to 512-byte blocks.
2. Decrease the latency
Slow tranfer over the WAN is sometimes caused by low
bandwidth, but more usually it's due to high latency. If you
have a round-trip latency of 100ms between your client and
server then you can at most transfer 10-blocks of data per
second. If you can reduce the latency, then you can transfer
more blocks in any given period of time.
If you have a number of routers/sites that have direct
connectivity between themselves and they are geographically
closer to each other than back to your hub, one option you
have is to set up a router as the TFTP server.
Other than the above, there's perhaps the option of using
some other protocol which is TCP based e.g., FTP, SCP etc.,
as this might give better performance than TFTP.
As you may be aware, the way TFTP works is that it
transfers a single data packet containing one block of data,
and that packet must be acknowledged before the next packet
can be sent. With this in mind there are really only two
ways to increase TFTP performance.
1. Increase the TFTP blocksize
The default TFTP blocksize is 512-bytes, but if your
client and server both support
RFC 2348 TFTP Blocksize Option then the blocksize can be
increased to approximately 1450-bytes. There are
measurements in the aforementioned RFC that show a 2.8x
performance improvement when using 1428-byte blocks compared
to 512-byte blocks.
2. Decrease the latency
Slow tranfer over the WAN is sometimes caused by low
bandwidth, but more usually it's due to high latency. If you
have a round-trip latency of 100ms between your client and
server then you can at most transfer 10-blocks of data per
second. If you can reduce the latency, then you can transfer
more blocks in any given period of time.
If you have a number of routers/sites that have direct
connectivity between themselves and they are geographically
closer to each other than back to your hub, one option you
have is to set up a router as the TFTP server.
Other than the above, there's perhaps the option of using
some other protocol which is TCP based e.g., FTP, SCP etc.,
as this might give better performance than TFTP.
The Last but not LeastTechnology is dominated by
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt.
Ph.D
FAIR USE NOTICEThis site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
You can use PayPal to to buy a cup of coffee for authors
of this site
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society.We do not warrant the correctness
of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be
tracked by Google please disable Javascript for this site. This site is perfectly usable without
Javascript.
Blue
