As per Relevance of the word connection, we have this rfc below:
Network Working Group G.
Request for Comments: 916
October 1984
RELIABLE ASYNCHRONOUS TRANSFER PROTOCOL (RATP
Status of This
This RFC suggests a proposed protocol for the ARPA-
community, and requests discussion and suggestions for improvements
Distribution of this memo is unlimited
This paper proposes and specifies a protocol which allows
programs to reliably communicate over a communication link.
ensures that the data entering one end of the link if
arrives at the other end intact and unaltered. The protocol,
RATP, is designed to operate over a full duplex point-to-
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
computer market. Such inexpensive computers are not
connected to a computer network. They are most likely stand-
devices. But virtually all of them have an RS-232 interface.
also usually have a modem. This allows them to communicate over
telephone with any other similarly equipped computer
The telephone system is a pervasive network, but one of
characteristics of the telephone system is the unpredictable
of the circuit. The standard telephone circuit is designed for
communication and not data communication. Voice
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
is a data circuit. Thus it is not uncommon for a byte of
transferred over a telephone circuit to have noise inserted. For
same reason it is also not uncommon to have spurious data bytes
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
personal computers grows, the need for them to communicate with
another grows as well. The new markets and new services that
computers will eventually allow their users to access will
heavily upon the telephone system. Services like electronic mail
electronic banking, ordering merchandise from home with a
computer, etc. As the information revolution proceeds data
will become a commodity. All require accuracy of the data sent
received
Finn [Page 1]
RFC 916 October 1984
Reliable Asynchronous Transfer
1. Philosopy of
Many tradeoffs were made in designing this protocol. Decisions
made by above all ensuring reliability and then by
simplicity of implementation. It is hoped that this protocol
simple enough to be implemented not only by small computers but
by stand alone devices incorporating microcomputers which
commands over RS-232 lines. Sophisticated but unnecessary
such as dynamic window management [TCP 81] were left out
simplicity's sake. Having several packets outstanding at a time
eliminated for the same reason, and data queued to send when
connection is closed remotely is discarded. This eliminates
states from the protocol implementation
The reader may ask why define this protocol at all, there are
all already RS-232 transport protocols in use. This is true but
lack one or more features vitally important or are too complex.
Appendix II for a brief survey
- A protocol which can only transfer data in one direction
unable to use a single RS-232 link for a full-duplex connection
As such it cannot act as a bridge between most
networks. Also it is not capable of supporting any
requiring the two-way exchange of data. In particular it is
a platform suitable for the creation of most higher
applications. Unidirectional flow of data is sufficient for
weak implementation of file transfer but insufficient for
terminal service, transaction oriented processing, etc
- Some of the existing RS-232 transport protocols allow the use
only fixed size packets or do not allow the receiver to place
limit on the sender's packets. Where that block size is
large for the receiving end concentrator, that concentrator
likely to immediately invoke flow control. This results in
dropped and damaged packets. The receiver must be able
inform the sender at connection initiation what is the
packet size it is prepared to receive
- Some protocols have a number of features which may or may not
implemented at each site. Examples are, several
algorithms, differing data transmission restrictions,
8-bit data, sometimes restricted ASCII subsets, etc.
resulting requirement that all sites implement all the
features is rarely met
Finally, the size of this document may be imposing. The
attempts to fully specify the behavior of the protocol. A
Finn [Page 2]
RFC 916 October 1984
Reliable Asynchronous Transfer
exposition of the protocol's behavior under all circumstances
necessary to answer any questions an implementor might have, to
it possible to verify the protocol, etc. This size of
specification should not be taken as an indication of the
of implementing it
1.1. The Host
This protocol is designed to operate on any point-to-
communication link capable of transmitting and receiving data.
is not necessary that the link be asynchronous. Because
end of a connection has control over when the other decides
transmit, the link should be full duplex. It is expected that
the vast majority of circumstances an asynchronous full-
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
to the user software level. Ideally it properly resides
the host operating system or concentrator. It should be an
associated with communication link which is selectable by the
program. If reliable data transmission were of great
then the software would choose the option. Once the option
chosen the initial connection handshaking would begin
There are many cases where this protocol will not reside in a
operating system (initially this will always be so). In
there are many pieces of stand-alone equipment which
commands over an RS-232 link. A plotter is such an example.
have a several hour plot ruined by noise on an unreliable
line is an all too often occurrence. The sending and
sides of the protocol should be as simple as possible
applications software and stand alone devices to utilize
protocol with little penalty of time or space
1.2. Relation to Other
The "layering" concept has become the accepted way of
communications protocols. Because this protocol will operate in
point-to-point environment it comprises both the datagram
reliable connection layers. No multi-network capability
implied. Where a link using this protocol bridges
networks it is expected that other protocols like TCP will
their packets fragmented and encapsulated inside the packets
this protocol
Finn [Page 3]
RFC 916 October 1984
Reliable Asynchronous Transfer
2. Packet
RATP transmits data over a full-duplex communication link. Data
be transmitted in both directions over the link. A stream of data
communicated by being broken up into 8-bit pieces called octets
These octets are serially accumulated to form a packet. The
is the unit of data communicated over the link. The
virtually guarantees that the data transmitted at one end,
received, arrives unaltered and intact at the other end
Within an octet all eight bits contain data. All eight bits must
preserved by the link interface and associated device driver.
many operating systems this is ensured by placing the connection
RAW or BINARY data mode. During normal operation packets
transmitted and acknowledged one at a time over the link in
direction. Each packet is composed of a HEADER followed by a
portion. The DATA portion may be empty
NOTE: There are some older operating systems and devices which
not permit 8-bit communication over an RS-232 link. Most of
allow restricted 7-bit communication. RATP can
detect this situation during connection initiation and utilizes
special packing strategy when full 8-bit communication is
possible. This is entirely transparent to any client software
See Appendix I for a discussion of this case
Finn [Page 4]
RFC 916 October 1984
Reliable Asynchronous Transfer
2.1. Header
Byte No
+-------------------------------+
| |
1 | Synch Leader | Hex 01
| |
+-------------------------------+
| S | A | F | R | S | A | E | S |
2 | Y | C | I | S | N | N | O | O |
| N | K | N | T | | | R | |
+-------------------------------+
| |
3 | Data length (0-255) |
| |
+-------------------------------+
| |
4 | Header Checksum |
| |
+-------------------------------+
Header Portion of a
2.1.1. Synch
RS-232 provides a self-clocking communications medium.
wires over which data flows are often placed in 'noisy
environments where the noise can appear as added unwanted data
For this reason the beginning of a packet is denoted by a
octet SYNCH pattern. This allows the receiver to discard
which appears on the connection prior to the reception of
packet. The SYNCH pattern is defined to be the one octet
01, the ASCII Start Of Header character .
The SYNCH pattern should ideally be unlikely to occur as
result of noise. Differing modems, etc. have
responses to noise so this is hard to achieve. The
chosen is thought to be a good compromise since many
manifest noise by setting the high order bits. Situations
occur in which receiver is scanning for the beginning of
packet and a spurious SYNCH pattern is seen. To
situations of this type a header checksum is provided (
below).
Finn [Page 5]
RFC 916 October 1984
Reliable Asynchronous Transfer
2.1.2. Control
The first octet following the SYNCH pattern contains a 5-
field of control flags and two 1-bit sequence number fields
The last bit is reserved and must be zero
2.1.2.1. SYN - Synchronize
Synchronize the connection. No data may be sent in a
which has the SYN flag set
2.1.2.2. ACK - Acknowledge
Acknowledge number is significant. Data may accompany
packet which has this flag set as long as neither of SYN
RST, nor FIN are also set. Once a connection has
established this is always set
2.1.2.3. RST - Reset
Reset the connection. This is a method by which one end
a connection can reset the other when an anomalous
is detected. No data may be sent in a packet which has
RST flag set
2.1.2.4. FIN - Finishing
This indicates that no more data will be sent to the
end of the connection. It also indicates that no more
will be accepted. No data may be sent in a packet which
the FIN flag set
2.1.2.5. SN - Sequence
The Sequence Number associated with this packet
2.1.2.6. AN - Acknowledge
If the ACK control flag is set this is the next
Number the sender of the packet is expecting to receive
2.1.2.7. EOR - End of
This bit is provided as an aid for higher level
which may need to fragment their packets. The
protocol for example often uses packets as large as 576
octets. A packet of such size would require
Finn [Page 6]
RFC 916 October 1984
Reliable Asynchronous Transfer
when transported using this protocol. The EOR bit if
provides information to the higher level that a record
terminated in this packet. It is for information only
is the responsibility of the higher level to set/clear
when building packets to send. The interface to
protocol must provide a method of reading/setting/
this bit
2.1.2.8. SO - Single
One application thought to be of special importance
single character transmission --- a user communicates
the keyboard of a personal computer to another computer
an unreliable link. Since rapid interactive response
desirable it is expected that many of the characters
will be transmitted individually. To minimize the
of this special case the SO control flag is provided
The SO flag has no meaning if either the SYN, RST, or
flags are set. Assume none of those flags are set, then
the SO flag is set it indicates that a single octet of
is contained in this packet. Since the amount of data
known to be one octet the LENGTH field is superfluous
itself contains the data octet. The data portion of
packet is not transmitted
The SO flag removes the need to transmit the data portion
the packet in this special case. Without the SO flag
octets would be required of the packet, with it only
are needed and so transmission efficiency is improved by 40
percent. The header checksum protects the single octet
data
2.1.3.
The second octet following the SYNCH pattern holds
information. If the SYN bit is present this contains
maximum number of data octets the receiver is allowed
transmit in any single packet to the sender. This quantity
called the MDL. A sender may indicate his unwillingness
accept any data octets by specifying an MDL of zero. In
case presumably all the data would be moving from the sender
the receiver. Obviously if data is to be transmitted
sides of a connection cannot have an MDL of zero
If neither the SYN, RST, nor FIN flags are set this is an 8-
field called LENGTH. In this case if the SO flag bit is
Finn [Page 7]
RFC 916 October 1984
Reliable Asynchronous Transfer
then LENGTH contains a single octet of data. Otherwise
contains the count of data octets in this packet. From
(0) to MDL octets of data may appear in a single packet.
is limited to a maximum of 255.
2.1.4. Header
The header checksum algorithm is the 8-bit equivalent of
16-bit data checksum detailed below. It is built and
in an similar manner but is eight bits wide instead of sixteen
When sending the header checksum octet is initially cleared
An 8-bit sum of the control, length, and header checksum
is formed employing end-around carry. That sum is
complemented and stored in the header checksum octet.
receipt the 8-bit end-around carry sum is formed of the
three octets. If the sum is octal 377 the header is
to be valid. In all other cases the header is assumed to
invalid
The reasons for providing this separate protection to
header are discussed in the chapter dealing with
handling. The header checksum covers the control and
length octets. It does not include the SYNCH pattern
2.2. Data
The data portion of a packet immediately follows the header if
SO flag is not set and LENGTH > 0. It consists of LENGTH
octets immediately followed by two data checksum octets.
present the data portion contains LENGTH+2 octets
Finn [Page 8]
RFC 916 October 1984
Reliable Asynchronous Transfer
Data Byte No
+-------------------------------+
1 | | High order \
+-- --+ >
2 | | Low order /
+-- --+
. | Data | High order \
+-- --+ >
. | | Low order /
+-- --+
LENGTH | | High order \
+-------------------------------+ >
| Imaginary padding octet 0 | Low order /
+-------------------------------+
LENGTH+1 | | High order \
+-- Data Checksum --+ >
LENGTH+2 | | Low order /
+-------------------------------+
Data Portion of a
2.2.1. Data
The last two octets of the data portion of a packet are a
checksum. A 16-bit checksum is used by this protocol to
incorrectly transmitted data. This has shown itself to be
reliable method for detecting most categories of bit drop
and bit insertion. While it does not guarantee the
of all such errors the probability of such an error
undetected is on the order of 2**(-16).
The checksum octets follow the data to enable the sender of
packet to compute the checksum while transmitting a packet
the receiver to compute the checksum while receiving
packet. Thus neither must store the packet and then
the data for checksumming in a separate pass
Order of
The order in which the 8-bit octets are assembled
16-bit words, which is the low order octet and which is
high, must be rigidly specified for the purpose of
16-bit checksums. We specify the big endian ordering in
diagram above [Cohen 81].
Finn [Page 9]
RFC 916 October 1984
Reliable Asynchronous Transfer
Checksum
The checksum algorithm chosen is similar to that used
IP/TCP protocols [IP 81] [TCP 81]. This algorithm has
itself to be both reliable and relatively easy to compute
The interested reader may refer to [TCP Checksum 78] for
more thorough discussion of its properties
The checksum algorithm is
The unsigned sum of the 16-bit words of the data
of the packet is formed. Any overflow is added into
lowest order bit. This sum does not include the
portion of the packet. For the purpose of building
packet for transmission the two octet checksum field
zero. The sum formed is then bit complemented
inserted into the checksum field before transmission
If the total number of data octets is odd then the
octet is padded to the right (low order) with zeros
form a 16-bit word for checksum purposes. This pad
is not transmitted as part of the packet
The sum is computed as above but including the
received in the checksum field. If the 16-bit sum
octal 177777 then the data is presumed to be valid.
all other cases the data is presumed to be invalid
This unsigned 16-bit sum adds 16-bit quantities with
overflow bit added into the lowest order bit of the sum.
is called 'end around carry'. End around carry
provides several properties: 1) It provides full commutivity
addition (summing in any order is equivalent), and 2) If
apply a given rotation to each quantity before addition
when the final total is formed apply the inverse rotation,
the result will be equivalent to any other rotation chosen
The latter property gives little endian machines like a PDP-11
the go ahead to pick up 16-bit quantities and add them in
swapped order
Finn [Page 10]
RFC 916 October 1984
Reliable Asynchronous Transfer
The PDP-11 code to calculate the checksum is
CLR R0 ; R0 will get the
; R2 contains LENGTH
LOOP: ADD (R1)+,R0 ; Add the next 16-bit
ADC R0 ; Make any carry be end
SOB R2,LOOP ; Loop over entire
COM R0 ; Bit complement
2.3. Sequence
Sequence numbers work with acknowledge numbers to inform
sender that his last data packet was received, and to inform
receiver of the sequence number of the next data packet it
to see. When the ACK flag is set in a packet the AN
contains the sequence number of the next data packet it
from the sender. The sender looks at the AN field and
implication knows that the packet he just sent should have had
sequence number of
received-1 modulo 2>
If it did have that number that packet is considered to have
acknowledged
Similarly, the receiver expects the next data packet it sees
have an SN field value equal to the AN field of the
acknowledge message it sent. If this is not the case then
receiver assumes that it is receiving a duplicate of a data
it earlier acknowledged. This implies that the packet
the acknowledgment did not arrive and therefor the packet
contained the acknowledgment should be retransmitted.
duplicate data packet is discarded
The only packets which require acknowledgment are
containing status flags (SYN, RST, FIN, or SO) or data. A
which contains only an acknowledgment, i.e. ,
not require a response (it contains no status flags or data).
Both the AN and SN fields are a single bit wide. Since at
one packet is in the process of being sent/acknowledged in
particular direction at any one time a single bit is sufficient
provide a method of duplicate packet detection and removal of
packet from the retransmission queue. The arithmetic to
these numbers is modulo 2. Thus when a data packet has
acknowledged the sender's next sequence number will be the
one, plus one modulo 2:
Finn [Page 11]
RFC 916 October 1984
Reliable Asynchronous Transfer
The individual acknowledgment of each packet containing data
mislead one into thinking that side A of a connection cannot
data to side B until it receives a packet from B. That only
can it acknowledge B's packet and place in the
packet some data of its own. This is not the case
As long as its last packet sent requiring a response has
acknowledged each side of a connection is free to send a
packet whenever it wishes. Naturally, if one side is sending
data packet and it also must acknowledge receipt of a data
from the other side, it is most efficient to combine
functions in a single packet
2.4. Maximum Packet
The maximum packet size is
SYNCH + HEADER + Data Checksum + 255 = 261
There is therefor no need to allocate more than that amount
storage for any received packets
Finn [Page 12]
RFC 916 October 1984
Reliable Asynchronous Transfer
3. The Opening and Closing of a
3.1. Opening a
A "three-way handshake" is the procedure used to establish
connection. It is normally initiated by one end of the
and responded to by the other. It will still work if both
simultaneously initiate the procedure. Experience has shown
this strategy of opening a connection reduces the probability
false connections to an acceptably low level
The simplest form of the three-way handshake is illustrated in
diagram below. The time order is line by line from top to
with certain lines numbered for reference. User events are
in brackets as in [OPEN]. An arrow (-->) represents the
of flow of a packet and an ellipsis (...) indicates a packet
transit. Side A and side B are the two ends of the connection
An "XXX" indicates a packet which is lost or rejected.
contents of the packet are shown on the center of each line.
state of both connections is that caused by the departure
arrival of the packet represented on the line. The contents
the data portion of a packet are left out for clarity
Side A Side
1. CLOSED
2. [OPEN request
SYN-SENT -> ...
3. --> SYN-
... <--
4. ESTABLISHED <--
--> ...
5. -->
In line 2 above the user at side A has requested that a
be opened. Side A then attempts to open a connection by sending
SYN packet to side B which is in the LISTEN state. It
its initial sequence number, here zero. It places in the
field of the header the largest number of data octets it
consume in any one packet (MDL). The MDL is normally positive
The action of sending this packet places A in the SYN-SENT state
In line 3 side B has just received the SYN packet from A.
Finn [Page 13]
RFC 916 October 1984
Reliable Asynchronous Transfer
places B in the SYN-RECEIVED state. B now sends a SYN packet to
which acknowledges the SYN it just received from A. Note that
AN field indicates B is now expecting to hear SN=1,
acknowledging the SYN packet from A which used SN=0. B
specifies in the LENGTH field the largest number of data octets
is prepared to consume
Side A receives the SYN packet from B which acknowledges A'
original SYN packet in line 4. This places A in the
state. Side A can now be confident that B expects to receive
packets from A
A is now free to send B the first DATA packet. In line 5
receipt of this packet side B is placed into the
state. DATA cannot be sent until the sender is in the
state. This is because the LENGTH field is used to specify
MDL when opening the connection
3.2. Recovering from a Simultaneous Active
It is of course possible that both ends of a connection may
to perform an active OPEN simultaneously. In this case
end of the connection is in the LISTEN state, both send
packets. A reliable bidirectional protocol must recover from
situation. It should recover in such a manner that the
is successfully initiated
Finn [Page 14]
RFC 916 October 1984
Reliable Asynchronous Transfer
Side A Side
1. CLOSED
2. [OPEN request
SYN-SENT --> ...
3. ... [OPEN request
<-- SYN-
4. --> SYN-
... <--
5. (packet finally arrives
SYN-RECEIVED <--
--> -->
... <--
6. (packet finally arrives
ESTABLISHED <--
--> ...
During simultaneous connection both sides of the
cycle from the CLOSED state through SYN-SENT to SYN-RECEIVED
and finally to ESTABLISHED
3.3. Detecting a Half-Open
Any computer may crash after a connection has been established
After recovering from the crash it may attempt to open a
connection. The other end must be able to detect this
and treat it as an error
Finn [Page 15]
RFC 916 October 1984
Reliable Asynchronous Transfer
Side A
1. ESTABLISHED
--> ...
-->
(crashes
2. XXX <--
3. (attempts to open new connection )
--> -->
... <-- (abort
4. <--
(connection refused
3.4. Closing a
Either side may choose to close an established connection.
is accomplished by sending a packet with the FIN control bit set
No data may appear in a FIN packet. The other end of
connection responds by shutting down its end of the connection
sending a FIN, ACK in response
Side A Side
1. ESTABLISHED
2. [CLOSE request from user
FIN-WAIT --> ...
3. --> LAST-
... <--
4. TIME-WAIT <--
--> ...
5. -->
6. (after 2*SRTT time passes
In line 2 the user on side A of the fully opened connection
decided to close it down by issuing a CLOSE call. No more
Finn [Page 16]
RFC 916 October 1984
Reliable Asynchronous Transfer
will be accepted for sending. If data remains unsent a
"Warning: Unsent data remains." is communicated to the user.
more data will be received. A packet containing a FIN but no
is constructed and sent. Side A goes into the FIN-WAIT state
Side B sees the FIN sent and immediately builds a FIN, ACK
in response. It then goes into the LAST-ACK state. The FIN,
packet is received by side A and an answering ACK is
sent. Side A then goes to the TIME-WAIT state. In line 5 side
receives the final acknowledgment of its FIN, ACK packet and
to the CLOSED state. In line 6 after waiting to be sure its
acknowledgment was received side A goes to the CLOSED state (
is the Smoothed Round Trip Time and is defined in section 6.3.1).
Finn [Page 17]
RFC 916 October 1984
Reliable Asynchronous Transfer
4. Packet
The act of receiving a packet is relatively straightforward.
are a few points which deserve some discussion. This chapter
discuss packet reception stage by stage in time order
Synch
The first stage in the reception of a packet is the discovery of
SYNCH pattern. Octets are read continuously and discarded
the SYNCH pattern is seen. Once SYNCH has been observed
to the Header Reception stage
Header
The remainder of the header is three octets in length. No
processing can continue until the complete header has been read
Once read the header checksum test is performed. If this
fails it is assumed that the current SYNCH pattern was the
of a data error. Since the correct SYNCH may appear
after the current one, go back to the Synch Detection stage
treat the three octets of the header following the bad SYNCH
new input
If the header checksum test succeeds then proceed to the
Reception stage
Data
A determination of the remaining length of the packet is made.
either of the SYN, RST, SO, or FIN flags are set then legally
entire packet has already been read and it is considered to
'arrived'. No data portion of a packet is present when one
those flags is set. Otherwise the LENGTH field specifies
remaining amount of data to read. In this case if the
field is zero then the packet contains no data portion and it
considered to have arrived
We now assume that a data portion is present and LENGTH
non-zero. Counting the data checksum LENGTH+2 octets must now
read. Once read the data checksum test is performed. If
test fails the entire packet is discarded, return to the
Detection stage. If the test succeeds then the packet
considered to have arrived
Finn [Page 18]
RFC 916 October 1984
Reliable Asynchronous Transfer
Once arrived the packet is released to the upper level
software. In a multiprocess implementation packet reception
now begin again at the Synch Detection stage
Finn [Page 19]
RFC 916 October 1984
Reliable Asynchronous Transfer
5. Functional
A convenient model for the discussion and implementation of
is that of a state machine. A connection can be thought of
passing through a variety of states, with possible error conditions
from its inception until it is closed. In such a model each
represents a known point in the history of a connection.
connection passes from state to state in response to events.
events are caused by user calls to the protocol interface (a
to open or close a connection, data to send, etc.), incoming packets
and timeouts
Information about a connection must be maintained at both ends
that connection. Following the terminology of [TCP 81]
information necessary to the successful operation of a connection
called the Transmission Control Block or TCB. The user requests
the protocol interface are OPEN, SEND, RECEIVE, ABORT, STATUS,
CLOSE
This chapter is broken up into three parts. First a
description of each protocol state will be presented. Following
is a slightly more detailed look at the allowed transitions
occur between states. Finally a detailed discussion of the
of each state is given
5.1. Protocol
The states used to describe this protocol are
This state represents waiting for a connection from
other end of the link
SYN-
This represents waiting for a matching connection
after having sent a connection request
SYN-
This represents waiting for a confirming connection
acknowledgment after having both received and sent
connection request
Finn [Page 20]
RFC 916 October 1984
Reliable Asynchronous Transfer
This state represents a connection fully opened at
ends. This is the normal state for data transfer
FIN-
In this state one is waiting for a connection
request from the other end of the connection and
acknowledgment of a termination request previously sent
LAST-
This end of the connection has seen and acknowledged
termination request from the other end. This end
responded with a termination request of its own and is
expecting an acknowledgment of that request
This represents waiting for an acknowledgment of
connection termination request
TIME-
This represents waiting for enough time to pass to be
that the other end of the connection received
acknowledgment of its termination request
A fictional state which represents a completely
connection. If either end of a connection is in this
it will neither send nor receive data or control packets
Finn [Page 21]
RFC 916 October 1984
Reliable Asynchronous Transfer
5.2. State
This section describes events which cause the protocol to
from its current state. A brief mention of each state
accompanied by a list of departure events and to which state
protocol goes as a result of those events. Departures due to
presence of a RST flag are not shown
5.2.1.
This is a request to listen for any connection from the
end of the link. In this state, no packets are sent.
connection may be thought of as half-open. A STATUS
will return to the caller this information
Arrived at from the CLOSED state in response to a passive OPEN
In a passive OPEN no packets are sent, the interface is
for the initiation of a connection from the other end of
link. Also this state can be reached in certain cases
response to an RST connection reset request
- A CLOSE request is made by the user. Delete the half-
TCB and go to the CLOSED state
- A packet arrives with the SYN flag set. Retrieve
sender's MDL he placed into the LENGTH field. Set AN
be received SN+1 modulo 2. Build a response packet
SYN, ACK set. Choose your MDL and place it into
LENGTH octet. Choose your initial SN, place in AN.
this packet and go to the SYN-RECEIVED state
5.2.2. SYN-
Arrived at from the CLOSED state in response to a user's
OPEN request
- A CLOSE request is made by the user. Delete the TCB
go to the CLOSED state
- A packet arrives with the SYN flag set. Retrieve
sender's MDL he placed into the LENGTH field. Set AN
Finn [Page 22]
RFC 916 October 1984
Reliable Asynchronous Transfer
be received SN+1 modulo 2. Build a response packet
ACK set, place in AN. Send this packet and go to
SYN-RECEIVED state
- A packet arrives with the SYN, ACK flags set.
the sender's MDL he placed into the LENGTH field. Set
to be received SN+1 modulo 2. Build a response
with ACK set. Set SN to be SN+1 modulo 2, place SN and
into the header. Remembering the other end's MDL,
data portion of packet. Send this packet and go to
ESTABLISHED state
5.2.3. SYN-
Arrived at from the LISTEN and SYN-SENT states in response
an arriving SYN packet
- A CLOSE request is made by the user. Create a packet
FIN set. Send it and go to the FIN-WAIT state
- A packet arrives with the ACK flag set. This
acknowledges a previous SYN packet. Go to the
state. The TCB should now note the connection is
opened
- A packet arrives with the FIN flag set. The other end
decided to close the connection. Create a packet
FIN, ACK set. Send it and go to the LAST-ACK state
5.2.4.
This state is the normal state for a connection. Data
may be exchanged in both directions (MDL allowing). It
arrived at from the SYN-RECEIVED and SYN-SENT states
response to the completion of connection initiation
- In response to a CLOSE request from the user. Set AN
be most recently received SN+1 modulo 2. Build a
with FIN set. Set SN to be SN+1 modulo 2, place SN and
into the header and send the packet. Go to the FIN-
state
- A packet containing a FIN is received. Set AN to
Finn [Page 23]
RFC 916 October 1984
Reliable Asynchronous Transfer
received SN+1 modulo 2. Build a response packet with
FIN and ACK set. Set SN to be SN+1 modulo 2, place SN
AN into the header. No data portion is built. Send
packet and go to the LAST-ACK state
5.2.5. FIN-
Arrived at from either the SYN-RECEIVED state or from
ESTABLISHED state. In both cases the user had requested
CLOSE of the connection and a packet with a FIN was sent
- A FIN, ACK packet is received which acknowledges the
just sent. Go to the TIME-WAIT state
- A FIN packet is received which indicates the other end
the connection has simultaneously decided to close.
AN=received SN+1 modulo 2, and SN=SN+1 modulo 2. Send
response packet with the ACK set. Go to the
state
5.2.6. LAST-
Arrived at from the ESTABLISHED and SYN-RECEIVED states
- An ACK is received for the last packet sent which was
FIN. Delete the TCB and go to the CLOSED state
5.2.7.
Arrived at from the FIN-WAIT state
- An ACK is received for the last packet sent which was
FIN. Go to the TIME-WAIT state
5.2.8. TIME-
Arrived at from the FIN-WAIT and CLOSING states
Finn [Page 24]
RFC 916 October 1984
Reliable Asynchronous Transfer
- This states waits until 2*SRTT time has passed. It
deletes the TCB associated with the connection and goes
the CLOSED state
5.2.9.
This state can be arrived at for a number of reasons: 1)
in the LISTEN state the user requests a CLOSE, 2) while in
SYN-SENT state the user requests a CLOSE, 3) while in
TIME-WAIT state the 2*SRTT time period has elapsed, and 4)
while in the LAST-ACK state an arriving packet has an ACK
the previously sent FIN packet
In this state no data is read or sent over the link. To
this state requires an outside request to open a
connection
- User requests an active OPEN. Create a packet with
set. Choose your MDL and place it into the LENGTH octet
Choose your initial SN. AN is immaterial. Send
packet and go to the SYN-SENT state. The TCB for
connection is created. The connection may be thought
as half-open. A STATUS request will return to the
this information
- User requests a passive OPEN. The TCB for this
is created. The connection may be thought of
half-open. A STATUS request will return to the
this information. Go to the LISTEN state
Finn [Page 25]
RFC 916 October 1984
Reliable Asynchronous Transfer
5.3. State
This section discusses in detail the behavior of each state
response to the arrival of a packet. In what follows a packet
not considered to have arrived until it has passed a number
tests (see the chapter entitled: Packet Reception).
The method chosen to describe state behavior is tabular.
state is listed opposite a sequence of named procedures to
whenever a packet has arrived
STATE
=============+========================
LISTEN |
-------------+------------------------
SYN-SENT |
-------------+------------------------
SYN-RECEIVED | C1 D1 E F1 H
-------------+------------------------
ESTABLISHED | C2 D2 E F2 H2 I
-------------+------------------------
FIN-WAIT | C2 D2 E F3 H
-------------+------------------------
LAST-ACK | C2 D3 E F3 H
-------------+------------------------
CLOSING | C2 D3 E F3 H
-------------+------------------------
TIME-WAIT | D3 E F3 H
-------------+------------------------
CLOSED |
-------------+------------------------
For example, in the ESTABLISHED state the arrival of a
causes procedure C2 to be executed, then D2, then E, F2, H2,
finally I1. Any procedure may terminate the processing
occurs or cause a state change. Note that these procedures
executed in sequence, first C2, then D2, etc. The time
cannot be mixed
The particular actions associated with each procedure are
described
Finn [Page 26]
RFC 916 October 1984
Reliable Asynchronous Transfer
A --------------------------------------------------------
This procedure details the behavior of the LISTEN state.
check the packet for the RST flag. If it is set then packet
discarded and ignored, return and continue the
associated with this state
We assume now that the RST flag was not set. Check the
for the ACK flag. If it is set we have an illegal
since no connection has yet been opened. Send a RST
with the correct response SN value
received AN>
Return to the current state without any further processing
We assume now that neither the RST nor the ACK flags were set
Check the packet for a SYN flag. If it is set then an
is being made to open a connection. Create a TCB for
connection. The sender has placed its MDL in the LENGTH field
also specified is the sender's initial SN value. Retrieve
place them into the TCB. Note that the presence of the SO
is ignored since it has no meaning when either of the SYN, RST
or FIN flags are set
Send a SYN packet which acknowledges the SYN received.
the initial SN value and the MDL for this end of
connection
received SN+1 modulo 2>
and go to the SYN-RECEIVED state without any
processing
Any packet not satisfying the above tests is discarded
ignored. Return to the current state without any
processing
Finn [Page 27]
RFC 916 October 1984
Reliable Asynchronous Transfer
B --------------------------------------------------------
This procedure represents the behavior of the SYN-SENT
and is entered when this end of the connection decides
execute an active OPEN
First, check the packet for the ACK flag. If the ACK flag
set then check to see if the AN value was as expected. If
was continue below. Otherwise the AN value was unexpected.
the RST flag was set then discard the packet and return to
current state without any further processing, else send
reset
received AN>
Discard the packet and return to the current state without
further processing
At this point either the ACK flag was set and the AN value
as expected or ACK was not set. Second, check the RST flag
If the RST flag is set there are two cases
1. If the ACK flag is set then discard the packet, flush
retransmission queue, inform the user "Error:
refused", delete the TCB, and go to the CLOSED state
any further processing
2. If the ACK flag was not set then discard the packet
return to this state without any further processing
At this point we assume the packet contained an ACK which
Ok, or there was no ACK, and there was no RST. Now check
packet for the SYN flag. If the ACK flag was set then our
has been acknowledged. Store MDL received in the TCB. At
point we are technically in the ESTABLISHED state. Send
acknowledgment packet and any initial data which is queued
send
received AN>received SN+1 modulo 2>
Go to the ESTABLISHED state without any further processing
If the SYN flag was set but the ACK was not set then the
end of the connection has executed an active open also
Acknowledge the SYN, choose your MDL, and send
received SN+1 modulo 2>
Finn [Page 28]
RFC 916 October 1984
Reliable Asynchronous Transfer
Go to the SYN-RECEIVED state without any further processing
Any packet not satisfying the above tests is discarded
ignored. Return to the current state without any
processing
C1 --------------------------------------------------------
Examine the received SN field value. If the SN value
expected then return and continue the processing
with this state
We now assume the SN value was not what was expected
If either RST or FIN were set discard the packet and return
the current state without any further processing
If neither RST nor FIN flags were set it is assumed that
packet is a duplicate of one already received. Send an
back
received AN>received SN+1 modulo 2>
Discard the duplicate packet and return to the current
without any further processing
C2 --------------------------------------------------------
Examine the received SN field value. If the SN value
expected then return and continue the processing
with this state
We now assume the SN value was not what was expected
If either RST or FIN were set discard the packet and return
the current state without any further processing
If SYN was set we assume that the other end crashed and
attempted to open a new connection. We respond by sending
legal reset
received AN>received SN+1 modulo 2>
This will cause the other end, currently in the SYN-SENT state
to close. Flush the retransmission queue, inform the
"Error: Connection reset", discard the packet, delete the TCB
and go to the CLOSED state without any further processing
Finn [Page 29]
RFC 916 October 1984
Reliable Asynchronous Transfer
If neither RST, FIN, nor SYN flags were set it is assumed
this packet is a duplicate of one already received. Send
ACK back
received AN>received SN+1 modulo 2>
Discard the duplicate packet and return to the current
without any further processing
D1 --------------------------------------------------------
The packet is examined for a RST flag. If RST is not set
return and continue the processing associated with this state
RST is now assumed to have been set. If the connection
originally initiated from the LISTEN state (it was
opened) then flush the retransmission queue, discard
packet, and go to the LISTEN state without any
processing
If instead the connection was initiated actively (came from
SYN-SENT state) then flush the retransmission queue, inform
user "Error: Connection refused", discard the packet,
the TCB, and go to the CLOSED state without any
processing
D2 --------------------------------------------------------
The packet is examined for a RST flag. If RST is not set
return and continue the processing associated with this state
RST is now assumed to have been set. Any data remaining to
sent is flushed. The retransmission queue is flushed, the
is informed "Error: Connection reset.", discard the packet
delete the TCB, and go to the CLOSED state without any
processing
D3 --------------------------------------------------------
The packet is examined for a RST flag. If RST is not set
return and continue the processing associated with this state
RST is now assumed to have been set. Discard the packet
delete the TCB, and go to the CLOSED state without any
processing
Finn [Page 30]
RFC 916 October 1984
Reliable Asynchronous Transfer
E --------------------------------------------------------
Check the presence of the SYN flag. If the SYN flag is not
then return and continue the processing associated with
state
We now assume that the SYN flag was set. The presence of a
here is an error. Flush the retransmission queue, send a
RST packet
If the ACK flag was set then send
received AN>
If the ACK flag was not set then send
The user should receive the message "Error: Connection reset.",
then delete the TCB and go to the CLOSED state without
further processing
F1 --------------------------------------------------------
Check the presence of the ACK flag. If ACK is not set
discard the packet and return without any further processing
We now assume that the ACK flag was set. If the AN field
was as expected then return and continue the
associated with this state
We now assume that the ACK flag was set and that the AN
value was unexpected. If the connection was
initiated from the LISTEN state (it was passively opened)
flush the retransmission queue, discard the packet, and send
legal RST packet
received AN>
Then delete the TCB and go to the LISTEN state without
further processing
Otherwise the connection was initiated actively (came from
SYN-SENT state) then inform the user "Error:
refused", flush the retransmission queue, discard the packet
and send a legal RST packet
Finn [Page 31]
RFC 916 October 1984
Reliable Asynchronous Transfer
received AN>
Then delete the TCB and go to the CLOSED state without
further processing
F2 --------------------------------------------------------
Check the presence of the ACK flag. If ACK is not set
discard the packet and return without any further processing
We now assume that the ACK flag was set. If the AN field
was as expected then flush the retransmission queue and
the user with an "Ok" if a buffer has been
acknowledged. Another packet containing data may now be sent
Return and continue the processing associated with this state
We now assume that the ACK flag was set and that the AN
value was unexpected. This is assumed to indicate a
acknowledgment. It is ignored, return and continue
processing associated with this state
F3 --------------------------------------------------------
Check the presence of the ACK flag. If ACK is not set
discard the packet and return without any further processing
We now assume that the ACK flag was set. If the AN field
was as expected then continue the processing associated
this state
We now assume that the ACK flag was set and that the AN
value was unexpected. This is ignored, return and
with the processing associated with this state
G --------------------------------------------------------
This procedure represents the behavior of the CLOSED state of
connection. All incoming packets are discarded. If the
had the RST flag set take no action. Otherwise it is
to build a RST packet. Since this end is closed the other
of the connection has incorrect data about the state of
connection and should be so informed
If the ACK flag was set then send
received AN>
Finn [Page 32]
RFC 916 October 1984
Reliable Asynchronous Transfer
If the ACK flag was not set then send
received SN+1 modulo 2>
After sending the reset packet return to the current
without any further processing
H1 --------------------------------------------------------
Our SYN has been acknowledged. At this point we
technically in the ESTABLISHED state. Send any initial
which is queued to send
received AN>received SN+1 modulo 2>
Go to the ESTABLISHED state and execute procedure I1 to
any data which might be in this packet
Any packet not satisfying the above tests is discarded
ignored. Return to the current state without any
processing
H2 --------------------------------------------------------
Check the presence of the FIN flag. If FIN is not set
continue the processing associated with this state
We now assume that the FIN flag was set. This means the
end has decided to close the connection. Flush
retransmission queue. If any data remains to be sent
inform the user "Warning: Data left unsent." The user
also be informed "Connection closing." An acknowledgment
the FIN must be sent which also indicates this end is closing
received AN>received SN + 1 modulo 2>
Go to the LAST-ACK state without any further processing
Finn [Page 33]
RFC 916 October 1984
Reliable Asynchronous Transfer
H3 --------------------------------------------------------
This state represents the final behavior of the FIN-WAIT state
If the packet did not contain a FIN we assume this packet is
duplicate and that the other end of the connection has not
the FIN packet we sent earlier. Rely upon retransmission
our earlier FIN packet to inform the other end of our desire
close. Discard the packet and return without any
processing
At this point we have a packet which should contain a FIN.
the rules of this protocol an ACK of a FIN requires a FIN,
in response and no data. If the packet contains data we
detected an illegal condition. Send a reset
received AN>received SN+1 modulo 2>
Discard the packet, flush the retransmission queue, inform
user "Error: Connection reset.", delete the TCB, and go to
CLOSED state without any further processing
We now assume that the FIN flag was set and no data
contained in the packet. If the AN field value was
then this packet acknowledges a previously sent FIN packet
The other end of the connection is then also assumed to
closing and expects an acknowledgment. Send an
of the FIN
received AN>received SN+1 modulo 2>
Start the 2*SRTT timer associated with the TIME-WAIT state
discard the packet, and go to the TIME-WAIT state without
further processing
Otherwise the AN field value was unexpected. This indicates
simultaneous closing by both sides of the connection. Send
acknowledgment of the FIN
received AN>received SN+1 modulo 2>
Discard the packet, and go to the CLOSING state without
further processing
Finn [Page 34]
RFC 916 October 1984
Reliable Asynchronous Transfer
H4 --------------------------------------------------------
This state represents the final behavior of the LAST-ACK state
If the AN field value is expected then this ACK is in
to the FIN, ACK packet recently sent. This is the
acknowledging message indicating both side's agreement to
the connection. Discard the packet, flush all queues,
the TCB, and go to the CLOSED state without any
processing
Otherwise the AN field value was unexpected. Discard
packet and remain in the current state without any
processing
H5 --------------------------------------------------------
This state represents the final behavior of the CLOSING state
If the AN field value was expected then this
acknowledges the FIN packet recently sent. This is the
acknowledging message indicating both side's agreement to
the connection. Start the 2*SRTT timer associated with
TIME-WAIT state, discard the packet, and go to the TIME-
state without any further processing
Otherwise the AN field value was unexpected. Discard
packet and remain in the current state without any
processing
H6 --------------------------------------------------------
This state represents the behavior of the TIME-WAIT state
Check the presence of the ACK flag. If ACK is not set
discard the packet and return without any further processing
Check the presence of the FIN flag. If FIN is not set
discard the packet and return without any further processing
We now assume that the FIN flag was set. This
indicates that the last acknowledgment of the FIN packet
by the other end of the connection did not arrive. Resend
acknowledgment
received AN>received SN+1 modulo 2>
Finn [Page 35]
RFC 916 October 1984
Reliable Asynchronous Transfer
Restart the 2*SRTT timer, discard the packet, and remain in
current state without any further processing
I1 --------------------------------------------------------
This represents that stage of processing in the
state in which all the flag bits have been processed and
data may remain. The packet is examined to see if it
data. If not the packet is now discarded, return to
current state without any further processing
We assume the packet contained data, that either the SO
was set or LENGTH is positive. That data is placed into
user's receive buffers. As these become full the user
be informed "Receive buffer full." An acknowledgment is sent
received AN>received SN+1 modulo 2>
If data is queued to send then it is most efficient
'piggyback' this acknowledgment on that data packet
The packet is now discarded, return to the ESTABLISHED
without any further processing
5.4.
There are three timers associated with this protocol.
purpose will now be briefly discussed as will the actions
when a timer expires. The particular nature these timeouts
and the methods by which they are set is the responsibility of
protocol implementation
5.4.1. User
For practical implementation reasons it is desirable to have
user controllable timeout associated with the
opening of a connection, successful acknowledgment of data,
successful closing of a connection. Consider the situations
which a connection is so noisy that no data gets through, or
connection is physically cut. Without an overriding
these situations would result in unbounded retransmissions
When this timeout expires the user is informed "Error
Connection aborted due to user timeout.", all queues
flushed, the TCB is deleted, and the CLOSED state is entered
Finn [Page 36]
RFC 916 October 1984
Reliable Asynchronous Transfer
5.4.2. Retransmission
This timer ensures that any packet sent for which the SN
significant is acknowledged. When such a packet is sent it
placed in a retransmission queue and the retransmission
is begun. If an acknowledgment has not arrived within
timer's period then the packet is retransmitted and the
is restarted. If the acknowledgment does arrive in time
the timer is stopped and the packet is removed from
retransmission queue. The next packet with a 