dnwcv@dcatla.UUCP (William C. VerSteeg) (07/11/88)
I am writing a TFTP file transfer program for a proprietary communications server. There appears to be some discrepancy between the TFTP document (IEN 133) and the packages that I have seen in use. Basically, the IEN calls for three type of files- netascii, binary, and mail. In addition to these types, I have seen "image", "octet", and "test" in the MIT package for the PC. I am not sure, but I think that I have seen other modes in other packages. My intent is to support netascii and binary file transfers. Mail mode is not well defined for my communications server (we have no embedded mail facility). The test mode also doesn't apply for this application. This leads me to my question. What other text strings should I expect to see in the mode field of a TFTP file access request? Is IEN 133 (dated Jan. 29 1980) the correct document to be referencing ? If it is, why are there conflicting text strings for binary mode ? Thanks Bill VerSteeg
dzoey@TERMINUS.UMD.EDU (07/12/88)
> From: dcatla!dnwcv@gatech.edu (William C. VerSteeg) > Subject: TFTP mode strings > There appears to be some discrepancy between the TFTP document (IEN > 133) and the packages that I have seen in use. Um, try reading RFC783 (June 1981) for the definitive (ugh) tftp treatment. > Basically, the IEN calls for three type of files- netascii, binary, and mail. TFTP encodes "netascii", "octet" or "mail" into the request packet. I've never seen "mail" implemented. Image, binary & test were never encoded in the packet and were just used for user-interface/debugging purposes. The thing to watch out for are retransmit wars. You can get into a mode where you are transmitting two packets for each packet you really want to send if you blindly ack all the packets that are retransmitted. I wound up just relying on a timer and ignoring the retransmits. Be careful of some older TFTP implementations. There was a bug in the 4.2 TFTP that made it confused when it received retransmitted packets. Since 4.2 begat such a large amount of derivitives, some implementations may still exhibit this problem. The problem was fixed in 4.3. There are lots of implementations existing to test against. Have fun. Joe Herman PC/IP @ Maryland dzoey@terminus.umd.edu
keith@spider.UUCP (07/15/88)
The problem with the TFTP standard is that although RFC 783 was published in 1981, the 1985 DDN protocol handbook still contains the superceded IEN 133, and has no reference to RFC 783. Somehow I managed to get as far as implementing TFTP without ever seeing RFC 783 !! (It is used for booting in our SpiderPort TCP/IP Ethernet terminal server.) Fortunately, there were plenty of implementations to test against, which made it clear the mode strings defined in IEN 133 were not those in real use - so SpiderPort uses "octet" mode. Can I suggest any future editions of the protocol handbook rectify this ? Keith Mitchell Spider Systems Ltd. keith@spider.co.uk 65 Bonnington Road keith%spider@uk.ac.hw.cs Edinburgh, Scotland keith%spider.co.uk@uunet.uu.net +44 31-554 9424 ...!uunet!ukc!spider!keith