|ISBN: 3423050012 ISBN: 3423050012 ISBN: 3423050012 ISBN: 3423050012|
RELIABLE ASYNCHRONOUS TRANSFER PROTOCOL (RATP)
Status of This Memo
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
This paper proposes and specifies a protocol which allows two programs to reliably communicate over a communication link. It ensures that the data entering one end of the link if received arrives at the other end intact and unaltered. The protocol, named RATP, is designed to operate over a full duplex point-to-point connection. It contains some features which tailor it to the RS-232 links now in common use.
We are witnessing today an explosive growth in the small or personal computer market. Such inexpensive computers are not normally connected to a computer network. They are most likely stand-alone devices. But virtually all of them have an RS-232 interface. They also usually have a modem. This allows them to communicate over the telephone with any other similarly equipped computer.
The telephone system is a pervasive network, but one of the characteristics of the telephone system is the unpredictable quality of the circuit. The standard telephone circuit is designed for voice communication and not data communication. Voice communication tolerates a much higher degree of 'noise' than does a data circuit, so a voice circuit is tolerant of a much higher level of noise than is a data circuit. Thus it is not uncommon for a byte of data transferred over a telephone circuit to have noise inserted. For the same reason it is also not uncommon to have spurious data bytes added to the data stream.
The need for a method of reliably transferring data over an RS-232 point-to-point link has become severe. As the number of powerful personal computers grows, the need for them to communicate with one another grows as well. The new markets and new services that these computers will eventually allow their users to access will rely heavily upon the telephone system. Services like electronic mail, electronic banking, ordering merchandise from home with a personal computer, etc. As the information revolution proceeds data itself will become a commodity. All require accuracy of the data sent or received.
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 exposition of the protocol's behavior under all circumstances is necessary to answer any questions an implementor might have, to make it possible to verify the protocol, etc. This size of this specification should not be taken as an indication of the difficulty of implementing it.
1.1. The Host Environment
This protocol is designed to operate on any point-to-point communication link capable of transmitting and receiving data. It is not necessary that the link be asynchronous. Because neither end of a connection has control over when the other decides to transmit, the link should be full duplex. It is expected that in the vast majority of circumstances an asynchronous full-duplex RS-232 link will be used.
In practice this protocol could reside anywhere from the RS-232 driver software on a microcomputer in a concentrator all the way to the user software level. Ideally it properly resides inside the host operating system or concentrator. It should be an option associated with communication link which is selectable by the user program. If reliable data transmission were of great importance then the software would choose the option. Once the option were chosen the initial connection handshaking would begin.
There are many cases where this protocol will not reside in a host operating system (initially this will always be so). In addition there are many pieces of stand-alone equipment which accept commands over an RS-232 link. A plotter is such an example. To have a several hour plot ruined by noise on an unreliable data line is an all too often occurrence. The sending and receiving sides of the protocol should be as simple as possible allowing applications software and stand alone devices to utilize the protocol with little penalty of time or space.
1.2. Relation to Other Protocols
The "layering" concept has become the accepted way of designing communications protocols. Because this protocol will operate in a point-to-point environment it comprises both the datagram and reliable connection layers. No multi-network capability is implied. Where a link using this protocol bridges differing networks it is expected that other protocols like TCP will have their packets fragmented and encapsulated inside the packets of this protocol.
||<< First < Previous Index Next > Last >>||
This web site is a part of the project ScientificPublication.com.
Back to the topic site:
External Links to this site are permitted without prior consent.
Realible Asynchronous Transfer Protocol
|deutsch | Set bookmark | Send a friend a link | Impressum|