FTP and TFTP

I wonder why the post does not appear immediately . It has taken many hours to appear ? Strange !! Strange.

I posted this message with subject 'FTP and TFTP' before posting a query with subject 'TFTP and FTP', It ('FTP and TFTP' msg) did not appear after waiting for nearly an hour. So, i reposted it with subject 'TFTP and FTP' assuming some problem in the post of 'TFTP and FTP'.

I think, i should wait for few hours after posting a message. Appologies.

Karthik Balaguru

"karthikbalaguru" ...

We did see it. It looked too much like your homework, and you should do that yourself to benefit from it.

Did you look it up in Wikipedia? Did you already completely study and understand the RFC's for FTP and TFTP?

Arie.

... snip ...

At time it may take Teranews several days to transfer my output messages. Admittedly this is abnormal. But remember, there are no transmission guarantees with Usenet.

Karthik Balaguru asked

Arie commented

Well, I have seen his posts here, so he's not just a carpetbagger on an urgent homework mission. FTP is a fairly complex protocol, which hands off the data transfer to separate port pair so that the control connection is available for further control traffic. TFTP is a very simplified functional analog, which just accepts a single command packet and sends multiple data packets in return. There is no connection, no error checking, no acknowledgements---so it doesn't need more ports.

...

You don't do his homework very good... (if it is homework).

- There is state, with timeouts - I see that as a connection.

- The error checking is in the checksums on the UDP and ETH layers. No need to add more. If the UDP were disabled (checksum zero) and another type of transport were used without a good CRC, I could agree. But that is unusual.

- No acknowledgements? Each packet has a block number and gets acknowledged with the block number. The TFTP protocol is "so slow" because the next packet will not be send before the previous packet's ACK is received. No windowing here.

Arie

I was sloppy, sorry, thanks for making me look it up again. I do believe I have a couple of points, though. Let's review:

Cmon, if you say it this way, everything would be a connection. What would qualify as a no-connection by your criteria? a single packet exchange?

While it's true that UDP nowadays tends to have checksum turned on, it really is no substitute for higher-level error detection and correction. Consider this: I just collected a sample of 100 UDP packets from my network, and four had invalid checksum. It could have been a crappy implementation of DNS in some embedded device, or a software flaw in a router; I don't care. Stevens discusses it here

Without the protocol-level checks, ya just can't trust the data, so you better do app-level checks. I'm happy that e.g. Linux kernel will do a boot-time sanity check while uncompressing because I wouldn't absolutely trust the boot image received over TFTP.

Yes, you're right, there are simple acks but the algorithm is the simplest possible and, ironically, vulnerable to both lockups and sorcerer's apprentice blowup in packet loss situations.

...

If at least one side remembers it's communication to someone else, e.g. remembers the remote side's IP and/or port number, and puts a timout on packet echange, and discards that information (a.k.a. disconnects) if a timeout occurs: I see that as a connection. TCP is called a connection - even when many minutes may go by without a single packet exchanged.

Agreed, the UDP checksum is not very good, although I have never seen a packet fail the UDP checksum (and we're streaming up to 500 channels of video using UDP/RTP). But then, it's over closed networks with switches and routers but not over the over the internet or leased lines. Routers that would modify packets are quickly discarded and never bought again.

Trust a kernel image? Hi, we do use TFTP for production programming of Linux kernel and initrd images - but we do use a CRC32 embedded in all images :-)

Agreed. I've also seen some bad implementations that hang after a single packet got lost (e.g. the original BSD tftp server).

Arie.

Or broadcast, or multicast without RTCP. A.k.a. "the shoot and forget" way of communication.

Arie