by Darius Kazemi, October 8 2019
RFC-281 is titled “A Suggested Addition to the File Transfer Protocol”. It's authored by Alex McKenzie of BBN and dated December 8, 1971.
The technical content
This RFC proposes a “restart” procedure be added to the File Transfer Protocol of RFC-265.
Basically, FTP has been designed thus far for transferring maybe a few pages of text at a time. But Remote Job Services will potentially need to send a lot more data. To remind you, a remote job service is something that lets you connect to a remote computer, enter the code for a computer program, and then have it work on that “job” for some period of time and send you the results at the end. You might be asking it to work overnight making millions of calculations for you, and the result might be hundreds of pages of data. The remote computer needs to be able to send you the results, and FTP seems like a good way to do that.
But FTP right now doesn't have great support for sending huge files. So the idea of the “restart” procedure is to be able to start over if there's a failure during a massive file transfer. This wouldn't be a complete restart, but it might involve going back to an earlier chunk of the file where you're positive everything was going okay and starting over from there. The author proposes using the sequence numbers for messages as a way of both user and server agreeing on what this position should be.
This “restart procedure” requires the creation of four new FTP commands:
- append at sequence number: begin appending data at a given point in the sequence
- retrieve at sequence number: begin reading data at a given point in the sequence
- use the sequence number: used as a reply to one of the above two commands, essentially saying “that sequence number you gave me was invalid, use this one instead”
- resume retrieve: assuming we stopped retriving a file earlier, this says “start again on that file at a given sequence number”
One really interesting consequence is that this means sequence numbers and files must be stored on non-volatile storage so that they won't just randomly change during a file transfer. Seems like the kind of thing that people would already be doing but storage is expensive in 1971 so I guess it makes sense that they'd avoid using it wherever possible!
There's also a very nice set of use cases that explain what the back-and-forth communication between the user and server would look like. I wish more documentation in 2019 had stuff like this.
How to follow this blog
You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@firstname.lastname@example.org” and follow it there.
Or, subscribe via email:
I'm Darius Kazemi. I'm an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.