RFC 916 (rfc916) - Page 2 of 54
Reliable Asynchronous Transfer Protocol (RATP)
Alternative Format: Original Text Document
RFC 916 October 1984 Reliable Asynchronous Transfer Protocol 1. Philosopy of Design Many tradeoffs were made in designing this protocol. Decisions were made by above all ensuring reliability and then by favoring simplicity of implementation. It is hoped that this protocol is simple enough to be implemented not only by small computers but also by stand alone devices incorporating microcomputers which accept commands over RS-232 lines. Sophisticated but unnecessary features such as dynamic window management [TCP 81] were left out for simplicity's sake. Having several packets outstanding at a time was eliminated for the same reason, and data queued to send when a connection is closed remotely is discarded. This eliminates two states from the protocol implementation. The reader may ask why define this protocol at all, there are after all already RS-232 transport protocols in use. This is true but some lack one or more features vitally important or are too complex. See Appendix II for a brief survey. - A protocol which can only transfer data in one direction is unable to use a single RS-232 link for a full-duplex connection. As such it cannot act as a bridge between most computer networks. Also it is not capable of supporting any applications requiring the two-way exchange of data. In particular it is not a platform suitable for the creation of most higher level applications. Unidirectional flow of data is sufficient for a weak implementation of file transfer but insufficient for remote terminal service, transaction oriented processing, etc. - Some of the existing RS-232 transport protocols allow the use of only fixed size packets or do not allow the receiver to place a limit on the sender's packets. Where that block size is too large for the receiving end concentrator, that concentrator is likely to immediately invoke flow control. This results in many dropped and damaged packets. The receiver must be able to inform the sender at connection initiation what is the maximum packet size it is prepared to receive. - Some protocols have a number of features which may or may not be implemented at each site. Examples are, several checksumming algorithms, differing data transmission restrictions, sometimes 8-bit data, sometimes restricted ASCII subsets, etc. The resulting requirement that all sites implement all the various features is rarely met. Finally, the size of this document may be imposing. The document attempts to fully specify the behavior of the protocol. A careful Finn
