Women in Technology

Hear us Roar

  TFTP and Error Correction
Subject:   Much like TCP...
Date:   2003-12-05 04:02:43
From:   anonymous2
Interesting... I note that two of those are (some of) the key features of TCP: Explicit packet acknowledgement and (if necessary) retransmission; and flow control (in TCPs case, packet sequence numbers). In fact, the only key thing missing that I can see are the start-of-connection and end-of-connection handshakes, which will be handled by the application anyway.
UDP is normally used in situations where either it doesn't matter if some packets are dropped, or where low latency is of extreme importance. Since the former is not the case where TFTP is concerned, and the latency will be very similar to TCP if you're explicitly acknowledging data transfer, is UDP used in this case purely because it's more lightweight to impliment?
Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • Much like TCP...
    2003-12-05 13:43:29  hjohns [View]

    Excellent point. TFTP is typically used only in very tight quarters, these days the only time you're likely to run into it is when booting over a network connection. In that case, the code for downloading the kernel etc. has got to fit into the bootloader (or network card), and they don't have the room to implement the whole tcp/ip stack, so TFTP serves as a kind of poor man's TCP.

    There is indeed an opening handshake (simpler than TCP's), but there isn't a closing one. Each TFTP data packet contains a 512 byte payload, except the last one. So when a packet shows up with less than 512 bytes, it's taken to mean that the transfer is complete.

    Ultimately, TFTP was an excercise in using the least possible amount of code to transfer a chunk of data over IP. If you've got a TCP stack lying around, it is infinitely preferable to use that.