365 RFCs

by Darius Kazemi, May 13 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Sorry, forget it

RFC-133 is titled “File Transfer and Error Recovery”. It's authored by R. L. Sunberg of Harvard, and is his only RFC.

The technical content

This document is three broad commentaries, one on File Transfer (RFC-114), one on error recovery in general, and one on NCP version identification.

It also contains some lovely “conversations” between server and client.

The author wants the server to have the “last work” in all file transfers, and all messages sent should prompt a response from the receiver. So there should be no such thing as a “fire and forget” message. Here's an example conversation between local and remote server file transfer, with the server notably at the end saying “All done”.

• Establish a connection
• Identify self
• Ok, ready
• Retrieval request
• I've got your file
• Send it
• Here's the first part
• Got it
• All done
• Store request
• Ok, go ahead
• Here's some protection stuff
• Ok
• Here's the file
• Got it. All done.

The author also recommends that there be mechanisms in FTP for addressing individual pieces of a file, which will be useful for extremely large files. He provides a formal mechanism to do so, which he recommends be added to the FTP spec.

In the next section, Sunberg notes that “[e]rror recovery procedures have been noticeably lacking to date” and mostly involve restarting the entire connection and trying the whole thing from the start if an error is detected at any point. He proposes a way to recover from a one-sided error that doesn't involve restarting the connection.

Here's his conversation that he uses to illustrate this:

• Send me this file
• Ok, I've got it
• Ready
• Here it is (with an error)
• No. (data) error
• Sorry, forget it
• Send the file (again)
• Ready (doesn't get there)
• (waiting)
• Error, timeout
• Sorry, forget it
• Send the file (third time)
• Got it
• Ready
• There it is
• Got it
• Done (finally)

If that doesn't work, then there should be a way to clear the link without closing any sockets. So it would be starting over but not completely, as an ICP would not need to be re-negotated. Finally, if that fails, the closing and opening the socket should be the last resort.

He also recommends that NCPs provide their version number so that a remote connection can tell what version of the NCP a host has implemented and can adjust accordingly.

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 “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm an independent technologist and artist. I do a lot of work on the decentralized web with both ActivityPub and the Dat Project. You can support my work via my Patreon.