Copyright Xerox Corporation 1979XEROX Palo Alto Research CenterJune 15, 1976To:Distributed ComputingFrom:John ShochSubject:EFTP: A PUP-based Ether File Transfer Protocolfile:eftpspec.pressThis document describes a means for simply moving files between two computers attached toa packet switched network. Known historically as the Experimental Ether File TransferProtocol (and now called simply EFTP), this mechanism can be used in a stand-aloneprogram, or as a program module embedded within other software systems. While theprotocol is not adequate for attacking the problems of more general file transfers, it does leadto an economical and reliable implementation.1. Companion DocumentsBackground information on the Ethernet, PUPs, and the Byte Stream Protocol (BSP):---Bob Metcalfe, PUP Specification, dated October 20, 1975.---Bob Metcalfe and David Boggs, Ethernet: Distributed Packet Switching for Local ComputerNetworks, November 1975 [to appear in CACM, 1976].---Ed Taft, Implementation of Pup in Tenex, dated October 28, 1975.Detailed description of a more general File Transfer Protocol:---John Shoch, A File Transfer Protocol Using the BSP -- 2nd edition, May 19, 1976.2. Assumptions and Basic Principles---A general mechanism for transferring files is described in the specification for the full FileTransfer Protocol. The principle characteristic of that design is the notion of a machine-independent file property list, supporting transfers among machines with very differentcharacteristics and operating system conventions. The current EFTP design (derived from theoriginal Experimental Ethernet File Transfer Protocol) does not provide all of those facilities,but the simplified protocol makes it easier to construct a separate file transfer module, whichcan then be used within other software systems.---An outline of the protocol can be found in the paper by Metcalfe and Boggs, cited above;although some important changes and improvements have been made.---Instead of using only Ethernet packets, the protocol now uses the more general definitionof a uniform packet, the PUP. The major impact of this change is to extend the effectiveaddressing capability of the protocol in order to communicate with hosts connected to othernetworks (and which must be reached through an inter-network gateway).---File transfers will generally take place between hosts; there is no attempt to supportmultiple file transfers at one time from one machine. For simplicity, the receiver will also be &pX \wqpr7Wp Vs(p Ss(p P s(r. Lp( FY EfH CA B\G @H ?R- 9>r 8c 64p8 4sp 3*!s* 1p* 0 sp .> -s"p (r# (0 %}pa #? "s s p9 2* i;% _ _/ U$7 @ D A2' ? 7F -+/ Isp  ;.ZfEFTP: A PUP-based Ether File Transfer Protocol2the server, and the sender of data will also be the user. Thus, unattended servers (such as aprinting host) can receive files; but it is not meaningful for an unattended user process toattempt to send a file. There is, therefore only a degenerate form of rendezvous: a user maylaunch packet 0 to socket 20 of the foreign host; the server may choose to acknowledge it,implicitly opening the connection.---The contents of a file move as an unnamed collection of bytes; the receiver must beprepared to name the file, or dispose of it appropriately.3. Details of the Protocol---There are only four packet types used:EFTPDataEFTPAckEFTPAbortEFTPEndThese are all registered PUP types, with the value carried in the PUP-type field. The lengthfield of the PUP is the byte count of the data, plus the PUP overhead. Note that the lengthmay be odd, in which case the PUP carries one byte of garbage at the end of the data section,which should be ignored.---Each data packet contains a sequence number, starting at 0. The sequence number iscarried in the low order 16 bits of the id field of the PUP (id^2, in PUP parlance).---There may not be more than one outstanding sequence number at any time; the sendermust receive a proper acknowledgement for packet n before he attempts to send packet n+1.If a proper ack is not returned, the sender should eventually timeout and retransmit. If anack should get lost, a receiver may get another copy of the previous packet; the data itcontains should not be re-processed, but the packet itself should be acknowledgedappropriately.---After transmitting the last data packet, and receiving an appropriate acknowledgment, thesender will transmit an EFTPEnd, with the next sequence number.---The receiver should verify this packet, and acknowledge it accordingly, but that is notsufficient. It is possible that the receiver would send the ack and then depart. Should thisack be lost, the sender would re-transmit the EFTPEnd. Since the receiver is no longerlistening, the sender would never get a response, and would not be able to verify that theconnection had been ended properly.---To handle this situation, a 'three-way handshake' takes place to terminate the connection.1. The sender transmits an EFTPEnd, in sequence.2. The receiver responds with an EFTPAck, but instead of departing he remains listening,performing a dally. The receiver knows that the file has been received completely, but thisextra dally period is done as a favor to the sender: should he fail to get the Ack and then re-transmit, the receiver will still be there to generate another Ack. Thus, the dally periodshould be long compared to the expected retransmission rate of the sender.3. When the sender finally receives the Ack for the first EFTPEnd, he now also knowsthat the transaction has been completed. It is possible, however, that the receiver is stilldallying at the other end; as a reciprocal favor, the sender now transmits another EFTPEnd,with the next sequence number, to release the receiver from the dally period. This packet isnot acknowledged, and will not be re-transmitted. In the best case, the receiver will get thesecond End, and promptly depart; in the worst case, the receiver will remain until the end ofthe dally period, and then depart, still secure in the knowledge that the whole file wasreceived. [It is worth noting that there is a finite probability that this scheme can fail: if the frX.G bpspspsp& `B _G ]W \ " Y!5 W{: Rr R] Op)2L2KS2I2HI E?= C P B5] @ =? 1~ .tC ,? )= (`L &J %V1) ## L2B02)/ 8 spJ D . N J2$I ,1 R ? 1- O E c ::.\[EFTP: A PUP-based Ether File Transfer Protocol3sender transmits the first EFTPEnd, misses the Ack, but then cannot retransmit until after thereceiver has finished dallying, he will never get the Ack. (This might happen if the senderwere interrupted, and was not able to respond for a lengthy period of time.) This probabilitycan be kept arbitrarily small, however, by insuring that the receiver's dally period is lengthycompared to the expected retransmission interval of the sender.]4. Aborts, Resets, and other messagesIt is hoped that this straightforward protocol can be modified slightly to provide one valuableservice: allow an automatic server to receive more than one file at a time (this would be veryuseful in a network printing server, for example). To support this, several abort and resetmechanisms have been provided.Packets of type EFTPAbort carry a machine readable abort code, as well as a human readableabort string: the abort code is carried in the first word of the data field, and the optionalstring therefore begins at byte 3. The length of the string is therefore equal to: puplength - (pupOvBytes + 2)A. Externally generated abortsCertain external conditions may cause a participant in a file transfer to request an abort: theuser/sender makes a mistake, the server/receiver realizes that the disk has become full, etc. Ifeither party is intending to drop a connection before the transfer is complete, it is consideredgood manners to launch an abort before leaving. There are two general codes provided (usersare encouraged to provide more specific textual error messages, whenever possible):ExternalSenderAbortExternalReceiverAbortB. Internally generated abortsThe EFTP mechanism may detect certain unusual conditions which require an abort or areset.1. While receiving one file, the server/receiver might refuse to respond at all to a packet fromanother source, and turn a deaf ear. Instead, the server will generate a non-fatal abortmessage, asking the second server to wait and try again soon. Thus, the second user mightchose to wait longer before giving up. [Note that the server program must be able torecognize the second incoming request, record the fact, and generate an appropriate Abort.]This would be a ReceiverBusyAbort.2. Should the server crash and restart, it may find itself receiving packets from a user whowas in the midst of a transaction. In this case the server will generate an OutOfSynchAbort,telling the user that synchronization has been lost; the user may attempt to restart, or merelyreport a failure.3. Should the user crash and start sending again, the server might suddenly find that packet 0is mysteriously arriving again. Rather than sending an Abort, this retransmission of packet 0(from the current foreign host) is taken as a request to restart the file transfer. Theserver/receiver can then reset the file, and begin again. Given this feature, a user mayexplicitly decide that something is wrong and request a reset by starting to transmmit from 0again. [This scheme would break down, of course, if there were ever 2^16 packets in onetransfer; but that is more data than can fit on most of our storage devices....] Note that thisreset does not require transmission of an EFTPAbort packet. frX.G bp7' `1+ _R ]H \ @ W{r% W$ TqpR R8' QgL O LK KS4) IS2F B5 ?+A =a " H 80- X . $] \ "6 "7 = D (8 ; :<.\4EFTP: A PUP-based Ether File Transfer Protocol45. A final noteThis protocol may be subject to substantial change, as the Reliable Packet Protocol becomesmore concrete. frX.G _ ^ , \ pC Z  T*:.,EFTP: A PUP-based Ether File Transfer Protocol5Appendix: Assignment of packet types and abort codes1. EFTPReceiveSocketBy convention, the EFTP receiver/server will run on socket #20.2. PUP types:EFTPData = #30EFTPAck = #31EFTPEnd = #32EFTPAbort = #33[known, of course, as error 33....]3. Abort codes (to be embedded within an EFTPAbort packet)ExternalSenderAbort= 1ExternalReceiverAbort= 2ReceiverBusyAbort= 3OutOfSynchAbort= 4 frX.G `5 Z W{p? QgrX N]p  L ( KS ( I sp Cr p, ?+ = : 9 17,$6] TIMESROMAN LOGO TIMESROMAN  TIMESROMAN   j/ %eftpspec.bravoTaftSeptember 3, 1979 6:36 PM