|
|
|
|
|
|
IETF RFC 908
Reliable Data Protocol
Last modified on Wednesday, September 23rd, 1992
 Permanent link to RFC 908
 Search GitHub Wiki for RFC 908
 Show other RFCs mentioning RFC 908
Reliable Data Protocol
RFC 908
David Velten
Robert Hinden
Jack Sax
BBN Communications Corporation
July 1984
 Status of This Memo
This RFC specifies a proposed protocol for the ARPA Internet
community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
RDP Specification
Table of Contents
1 Introduction.......................................... 1
2 General Description................................... 3
2.1 Motivation.......................................... 3
2.2 Relation to Other Protocols......................... 5
3 Protocol Operation.................................... 7
3.1 Protocol Service Objectives......................... 7
3.2 RDP Connection Management........................... 7
3.2.1 Opening a Connection.............................. 8
3.2.2 Ports............................................. 8
3.2.3 Connection States................................. 8
3.2.4 Connection Record................................ 11
3.2.5 Closing a Connection............................. 13
3.2.6 Detecting an Half-Open Connection................ 14
3.3 Data Communication................................. 14
3.4 Reliable Communication............................. 15
3.4.1 Segment Sequence Numbers......................... 15
3.4.2 Checksums........................................ 16
3.4.3 Positive Acknowledgement of Segments............. 16
3.4.4 Retransmission Timeout........................... 17
3.5 Flow Control and Window Management................. 17
3.6 User Interface..................................... 19
3.7 Event Processing................................... 20
3.7.1 User Request Events.............................. 21
3.7.2 Segment Arrival Events........................... 24
3.7.3 Timeout Events................................... 29
4 RDP Segments and Formats............................. 31
4.1 IP Header Format................................... 31
4.2 RDP Header Format.................................. 32
4.2.1 RDP Header Fields................................ 33
4.3 SYN Segment........................................ 36
4.3.1 SYN Segment Format............................... 36
4.3.2 SYN Segment Fields............................... 37
4.4 ACK Segment........................................ 38
4.4.1 ACK Segment Format............................... 38
4.4.2 ACK Segment Fields............................... 39
4.5 Extended ACK Segment............................... 40
4.5.1 EACK Segment Format.............................. 40
4.5.2 EACK Segment Fields.............................. 40
Page i
RFC 908 July 1984
4.6 RST Segment........................................ 42
4.6.1 RST Segment Format............................... 42
4.7 NUL Segment........................................ 43
4.7.1 NUL segment format............................... 43
5 Examples of Operation................................ 45
5.1 Connection Establishment........................... 45
5.2 Simultaneous Connection Establishment.............. 46
5.3 Lost Segments...................................... 47
5.4 Segments Received Out of Order..................... 48
5.5 Communication Over Long Delay Path................. 49
5.6 Communication Over Long Delay Path With Lost
Segments
.................................................... 50
5.7 Detecting a Half-Open Connection on Crash
Recovery
.................................................... 51
5.8 Detecting a Half-Open Connection from the
Active Side
.................................................... 52
A Implementing a Minimal RDP........................... 53
Page ii
RDP Specification
FIGURES
1 Relation to Other Protocols............................ 5
2 Form of Data Exchange Between Layers................... 6
3 RDP Connection State Diagram.......................... 10
4 Segment Format........................................ 31
5 RDP Header Format..................................... 32
6 SYN Segment Format.................................... 37
7 ACK Segment Format.................................... 38
8 EACK Segment Format................................... 41
9 RST Segment Format.................................... 42
10 NUL Segment Format................................... 43
Page iii
CHAPTER 1
Introduction
The Reliable Data Protocol (RDP) is designed to provide a
reliable data transport service for packet-based applications
such as remote loading and debugging. The protocol is intended
to be simple to implement but still be efficient in environments
where there may be long transmission delays and loss or non-
sequential delivery of message segments.
Although this protocol was designed with applications such
as remote loading and debugging in mind, it may be suitable for
other applications that require reliable message services, such
as computer mail, file transfer, transaction processing, etc.
Some of the concepts used come from a variety of sources.
The authors wish credit to be given to Eric Rosen, Rob Gurwitz,
Jack Haverty, and to acknowledge material adapted from "RFC 793,
The Transmission Control Protocol", edited by Jon Postel. Thanks
to John Linn for the checksum algorithm.
Page 1
RFC 908 July 1984
Page 2
RDP Specification General Description
CHAPTER 2
General Description
2.1 Motivation
RDP is a transport protocol designed to efficiently support
the bulk transfer of data for such host monitoring and control
applications as loading/dumping and remote debugging. It
attempts to provide only those services necessary, in order to be
efficient in operation and small in size. Before designing the
protocol, it was necessary to consider what minimum set of
transport functions would satisfy the requirements of the
intended applications.
The following is a list of requirements for such a transport
protocol:
o Reliable delivery of packets is required. When loading
or dumping a memory image, it is necessary that all
memory segments be delivered. A 'hole' left in the
memory image is not acceptable. However, the internet
environment is a lossy one in which packets can get
damaged or lost. So a positive acknowledgement and
retransmission mechanism is a necessary component of the
protocol.
o Since loading and dumping of memory images over the
internet involves the bulk transfer of large amounts of
data over a lossy network with potentially long delays,
it is necessary that the protocol move data efficiently.
In particular, unnecessary retransmission of segments
should be avoided. If a single segment has been lost but
succeeding segments correctly received, the protocol
should not require the retransmission of all of the
segments.
o Loading and dumping are applications that do not
necessarily require sequenced delivery of segments, as
long as all segments eventually are delivered. So the
protocol need not force sequenced delivery. For these
types of applications, segments may be delivered in the
order in which they arrive.
Page 3
RFC 908 July 1984
o However, some applications may need to know that a
particular piece of data has been delivered before
sending the next. For example, a debugger will want to
know that a command inserting a breakpoint into a host
memory image has been delivered before sending a
"proceed" command. If those segments arrived out of
sequence, the intended results would not be achieved.
The protocol should allow a user to optionally specify
that a connection must deliver segments in sequence-
number order.
o The loading/dumping and debugging applications are well-
defined and lend themselves to easy packetization of the
transferred data. They do not require a complex byte-
stream transfer mechanism.
In order to combine the requirements for bulk transfers of
data and reliable delivery, it is necessary to design a
connection-oriented protocol using a three-way handshake to
synchronize sequence numbers. The protocol seems to be
approaching TCP in complexity, so why was TCP not, in fact,
chosen? The answer is that TCP has some disadvantages for these
applications. In particular:
o TCP is oriented toward a more general environment,
supporting the transfer of a stream of bytes between two
communicating parties. TCP is best suited to an
environment where there is no obvious demarcation of data
in a communications exchange. Much of the difficulty in
developing a TCP implementation stems from the complexity
of supporting this general byte-stream transfer, and thus
a significant amount of complexity can be avoided by
using another protocol. This is not just an
implementation consideration, but also one of efficiency.
o Since TCP does not allow a byte to be acknowledged until
all prior bytes have been acknowledged, it often forces
unnecessary retransmission of data. Therefore, it does
not meet another of the requirements stated above.
o TCP provides sequenced delivery of data to the
application. If the application does not require such
sequenced delivery, a large amount of resources are
wasted in providing it. For example, buffers may be tied
up buffering data until a segment with an earlier
sequence number arrives. The protocol should not force
its segment-sequencing desires on the application.
Page 4
RDP Specification General Description
RDP supports a much simpler set of functions than TCP. The
flow control, buffering, and connection management schemes of RDP
are considerably simpler and less complex. The goal is a
protocol that can be easily and efficiently implemented and that
will serve a range of applications.
RDP functions can also be subset to further reduce the size
of a particular implementation. For example, a target processor
requiring down-loading from another host might implement an RDP
module supporting only the passive Open function and a single
connection. The module might also choose not to implement out-
of-sequence acknowledgements.
2.2 Relation to Other Protocols
RDP is a transport protocol that fits into the layered
internet protocol environment. Figure 1 illustrates the place of
RDP in the protocol hierarchy:
+------+ +-----+ +-----+ +------+
|TELNET| | FTP | |Debug| ... |Loader| Application Layer
+------+ +-----+ +-----+ +------+
| | | |
+-----+----+ +------+------+
| |
+------+ +-------+
| TCP | | RDP | Transport Layer
+------+ +-------+
| |
+--------------------------------+
| Internet Protocol & ICMP | Internetwork Layer
+--------------------------------+
|
+-------------------------+
| Network Access Protocol | Network Layer
+-------------------------+
Relation to Other Protocols
Figure 1
Page 5
RFC 908 July 1984
RDP provides the application layer with a reliable message
transport service. The interface between users and RDP transfers
data in units of messages. When implemented in the internet
environment, RDP is layered on the Internet Protocol (IP), which
provides an unreliable datagram service to RDP. Data is passed
across the RDP/IP interface in the form of segments. RDP uses
the standard IP interface primitives to send and receive RDP
segments as IP datagrams. At the internet level, IP exchanges
datagrams with the network layer. An internet packet may contain
an entire datagram or a fragment of a datagram.
# %
? * !
@ )
+------+ +-----+ +----+ $ = ^ +
| |Messages | |Segments | | Datagrams *
| User |<------->| RDP |<------->| IP |<-------> Internet
| | | | | | , ?
+------+ +-----+ +----+ ! )
* % $
@ ^ !
Form of Data Exchange Between Layers
Figure 2
If internetwork services are not required, it should be
possible to use the RDP without the IP layer. As long as the
encapsulating protocol provides the RDP with such necessary
information as addressing and protocol demultiplexing, it should
be possible to run RDP layered on a variety of different
protocols.
Page 6
RDP Specification Protocol Operation
CHAPTER 3
Protocol Operation
3.1 Protocol Service Objectives
The RDP protocol has the following goals:
o RDP will provide a full-duplex communications channel
between the two ports of each transport connection.
o RDP will attempt to reliably deliver all user messages
and will report a failure to the user if it cannot
deliver a message. RDP extends the datagram service of
IP to include reliable delivery.
o RDP will attempt to detect and discard all damaged and
duplicate segments. It will use a checksum and sequence
number in each segment header to achieve this goal.
o RDP will optionally provide sequenced delivery of
segments. Sequenced delivery of segments must be
specified when the connection is established.
o RDP will acknowledge segments received out of sequence,
as they arrive. This will free up resources on the
sending side.
3.2 RDP Connection Management
RDP is a connection-oriented protocol in which each
connection acts as a full-duplex communication channel between
two processes. Segments from a sender are directed to a port on
the destination host. The two 8-bit source and destination port
identifiers in the RDP header are used in conjunction with the
network source and destination addresses to uniquely identify
each connection.
Page 7
RFC 908 July 1984
3.2.1 Opening a Connection
Connections are opened by issuing the Open request, which
can be either active or passive. A passive Open request puts RDP
into the Listen state, during which it passively listens for a
request to open a connection from a remote site. The active Open
request attempts to establish a connection with a specified port
at a remote site.
The active Open request requires that a specific remote port
and host address be specified with the request. The passive Open
may optionally specify a specific remote port and network
address, or it may specify that an open be accepted from anyone.
If a specific remote port and host address were specified, an
arriving request to open a connection must exactly match the
specified remote port and address.
3.2.2 Ports
Valid port numbers range from 1 to 255 (decimal). There are
two types of ports: "well known" ports and "allocable" ports.
Well-known ports have numbers in the range 1 to 63 (decimal) and
allocable ports are given numbers in the range 64 to 255.
The user, when issuing an active Open request, must specify
both the remote host and port and may optionally specify the
local port. If the local port was not specified, RDP will select
an unused port from the range of allocable ports. When issuing a
passive Open request, the user must specify the local port
number. Generally, in this case the local port will be a well-
known port.
3.2.3 Connection States
An RDP connection will progress through a series of states
during its lifetime. The states are shown in Figure 3 and are
individually described below. In Figure 3, the boxes represent
the states of the RDP FSM and the arcs represent changes in
state. Each arc is annotated with the event causing the state
change and the resulting output.
Page 8
RDP Specification Protocol Operation
CLOSED
The CLOSED state exists when no connection exists and there
is no connection record allocated.
LISTEN
The LISTEN state is entered after a passive Open request is
processed. A connection record is allocated and RDP waits
for an active request to establish a connection from a
remote site.
SYN-SENT
The SYN-SENT state is entered after processing an active
Open request. A connection record is allocated, an initial
sequence number is generated, and a SYN segment is sent to
the remote site. RDP then waits in the SYN-SENT state for
acknowledgement of its Open request.
SYN-RCVD
The SYN-RCVD state may be reached from either the LISTEN
state or from the SYN-SENT state. SYN-RCVD is reached from
the LISTEN state when a SYN segment requesting a connection
is received from a remote host. In reply, the local RDP
generates an initial sequence number for its side of the
connection, and then sends the sequence number and an
acknowledgement of the SYN segment to the remote site. It
then waits for an acknowledgement.
The SYN-RCVD state is reached from the SYN-SENT state when a
SYN segment is received from the remote host without an
accompanying acknowledgement of the SYN segment sent to that
remote host by the local RDP. This situation is caused by
simultaneous attempts to open a connection, with the SYN
segments passing each other in transit. The action is to
repeat the SYN segment with the same sequence number, but
now including an ACK of the remote host's SYN segment to
indicate acceptance of the Open request.
Page 9
RFC 908 July 1984
+------------+
Passive Open | |<-------------------------+
+----------------| CLOSED | |
| Request | |---------------+ |
V +------------+ | |
+------------+ | |
| | | |
| LISTEN | | |
| | | |
+------------+ | |
| Active | |
| rcv SYN Open Request | |
| ----------- ------------ | |
| snd SYN,ACK snd SYN | |
V rcv SYN V |
+------------+ ----------- +------------+ |
| | snd SYN,ACK | | |
| SYN-RCVD |<-------------------------------| SYN-SENT | |
| | | | |
+------------+ +------------+ |
| rcv ACK rcv SYN,ACK | |
| ---------- ------------- | |
| xxx +------------+ snd ACK | |
| | | | |
+--------------->| OPEN |<--------------+ |
| | |
+------------+ |
rcv RST | Close request |
----------- | --------------- |
xxx | snd RST |
V |
+------------+ |
| | |
| CLOSE-WAIT |--------------------------+
| | After a Delay
+------------+
RDP Connection State Diagram
Figure 3
Page 10
RDP Specification Protocol Operation
OPEN
The OPEN state exists when a connection has been established
by the successful exchange of state information between the
two sides of the connection. Each side has exchanged and
received such data as initial sequence number, maximum
segment size, and maximum number of unacknowledged segments
that may be outstanding. In the Open state data may be sent
between the two parties of the connection.
CLOSE-WAIT
The CLOSE-WAIT state is entered from either a Close request
or from the receipt of an RST segment from the remote site.
RDP has sent an RST segment and is waiting a delay period
for activity on the connection to complete.
3.2.4 Connection Record
The variables that define the state of a connection are
stored in a connection record maintained for each connection.
The following describes some of the variables that would be
stored in a typical RDP connection record. It is not intended to
be an implementation specification nor is it a complete
description. The purpose of naming and describing some of the
connection record fields is to simplify the description of RDP
protocol operation, particularly event processing.
The connection record fields and their descriptions follow:
STATE
The current state of the connection. Legal values are OPEN,
LISTEN, CLOSED, SYN-SENT, SYN-RCVD, and CLOSE-WAIT.
Send Sequence Number Variables:
SND.NXT
The sequence number of the next segment that is to be sent.
Page 11
RFC 908 July 1984
SND.UNA
The sequence number of the oldest unacknowledged segment.
SND.MAX
The maximum number of outstanding (unacknowledged) segments
that can be sent. The sender should not send more than this
number of segments without getting an acknowledgement.
SND.ISS
The initial send sequence number. This is the sequence
number that was sent in the SYN segment.
Receive Sequence Number Variables:
RCV.CUR
The sequence number of the last segment received correctly
and in sequence.
RCV.MAX
The maximum number of segments that can be buffered for this
connection.
RCV.IRS
The initial receive sequence number. This is the sequence
number of the SYN segment that established this connection.
RCVDSEQNO[n]
The array of sequence numbers of segments that have been
received and acknowledged out of sequence.
Other Variables:
CLOSEWAIT
A timer used to time out the CLOSE-WAIT state.
SBUF.MAX
The largest possible segment (in octets) that can legally be
sent. This variable is specified by the foreign host in the
Page 12
RDP Specification Protocol Operation
SYN segment during connection establishment.
RBUF.MAX
The largest possible segment (in octets) that can be
received. This variable is specified by the user when the
connection is opened. The variable is sent to the foreign
host in the SYN segment.
Variables from Current Segment:
SEG.SEQ
The sequence number of the segment currently being
processed.
SEG.ACK
The acknowledgement sequence number in the segment currently
being processed.
SEG.MAX
The maximum number of outstanding segments the receiver is
willing to hold, as specified in the SYN segment that
established the connection.
SEG.BMAX
The maximum segment size (in octets) accepted by the foreign
host on a connection, as specified in the SYN segment that
established the connection.
3.2.5 Closing a Connection
The closing of a connection can be initiated by a Close
request from the user process or by receipt of an RST segment
from the other end of the connection. In the case of the Close
request, RDP will send an RST segment to the other side of the
connection and then enter the CLOSE-WAIT state for a period of
time. While in the CLOSE-WAIT state, RDP will discard segments
received from the other side of the connection. When the time-
out period expires, the connection record is deallocated and the
connection ceases to exist. This simple connection closing
facility requires that users determine that all data has been
Page 13
RFC 908 July 1984
reliably delivered before requesting a close of the connection.
3.2.6 Detecting an Half-Open Connection
If one side of a connection crashes, the connection may be
left with the other side still active. This situation is termed
to be an half-open connection. For many cases, the active RDP
will eventually detect the half-open connection and reset. Two
examples of recovery from half-open connections are provided in
sections 5.7 and 5.8. Recovery is usually achieved by user
activity or by the crashed host's attempts to re-establish the
connection.
However, there are cases where recovery is not possible
without action by the RDP itself. For example, if all connection
blocks are in use, attempts to re-establish a broken connection
will be rejected. In this case, the RDP may attempt to free
resources by verifying that connections are fully open. It does
this by sending a NUL segment to each of the other RDPs. An
acknowledgement indicates the connection is still open and valid.
To minimize network overhead, verification of connections
should only be done when necessary to prevent a deadlock
situation. Only inactive connections should be verified. An
inactive connection is defined to be a connection that has no
outstanding unacknowledged segments, has no segments in the user
input or output queues, and that has not had any traffic for some
period of time.
3.3 Data Communication
Data flows through an RDP connection in the form of
segments. Each user message submitted with a Send request is
packaged for transport as a single RDP segment. Each RDP segment
is packaged as an RDP header and one or more octets of data. RDP
will not attempt to fragment a large user message into smaller
segments and re-assemble the message on the receiving end. This
differs from a byte-stream protocol such as TCP which supports
the transfer of an indeterminate length stream of data between
ports, buffering data until it is requested by the receiver.
Page 14
RDP Specification Protocol Operation
At the RDP level, outgoing segments, as they are created,
are queued as input to the IP layer. Each segment is held by the
sending RDP until it is acknowledged by the foreign host.
Incoming segments are queued as input to the user process through
the user interface. Segments are acknowledged when they have
been accepted by the receiving RDP.
The receiving end of each connection specifies the maximum
segment size it will accept. Any attempt by the sender to
transmit a larger segment is an error. If RDP determines that a
buffer submitted with a Send request exceeds the maximum size
segment permitted on the connection, RDP will return an error to
the user. In addition, RDP will abort a connection with an RST
segment if an incoming segment contains more data than the
maximum acceptable segment size. No attempt will be made to
recover from or otherwise overcome this error condition.
If sequenced delivery of segments is necessary for a
connection, the requirement must be stated when the connection is
established. Sequenced delivery is specified when the Open
request is made. Sequenced delivery of segments will then be the
mode of delivery for the life of the connection.
3.4 Reliable Communication
RDP implements a reliable message service through a number
of mechanisms. These include the insertion of sequence numbers
and checksums into segments, the positive acknowledgement of
segment receipt, and timeout and retransmission of missing
segments.
3.4.1 Segment Sequence Numbers
Each segment transporting data has a sequence number that
uniquely identifies it among all other segments in the same
connection. The initial sequence number is chosen when the
connection is opened and is selected by reading a value from a
monotonically increasing clock. Each time a segment containing
data is transmitted, the sequence number is incremented.
Segments containing no data do not increment the sequence number.
However, the SYN and NUL segments, which cannot contain data, are
exceptions. The SYN segment is always sent with a unique
sequence number, the initial sequence number. The NUL segment is
Page 15
RFC 908 July 1984
sent with the next valid sequence number.
3.4.2 Checksums
Each RDP segment contains a checksum to allow the receiver
to detect damaged segments. RDP uses a non-linear checksum
algorithm to compute a checksum that is 32-bits wide and operates
on data in units of four octets (32 bits). The area that is
covered by the checksum includes both the RDP header and the RDP
data area.
If a segment contains a number of header and data octets
that is not an integral multiple of 4 octets, the last octet is
padded on the right with zeros to form a 32-bit quantity for
computation purposes. The padding zeros are not transmitted as
part of the segment. While computing the checksum, the checksum
field itself is replaced with zeros. The actual algorithm is
described in Section 4.2.1.
3.4.3 Positive Acknowledgement of Segments
RDP assumes it has only an unreliable datagram service to
deliver segments. To guarantee delivery of segments in this
environment, RDP uses positive acknowledgement and retransmission
of segments. Each segment containing data and the SYN and NUL
segments are acknowledged when they are correctly received and
accepted by the destination host. Segments containing only an
acknowledgement are not acknowledged. Damaged segments are
discarded and are not acknowledged. Segments are retransmitted
when there is no timely acknowledgement of the segment by the
destination host.
RDP allows two types of acknowledgement. A cumulative
acknowledgement is used to acknowledge all segments up to a
specified sequence number. This type of acknowledgement can be
sent using fixed length fields within the RDP header.
Specifically, the ACK control flag is set and the last
acknowledged sequence number is placed in the Acknowledgement
Number field.
The extended or non-cumulative acknowledgement allows the
receiver to acknowledge segments out of sequence. This type of
acknowledgement is sent using the EACK control flag and the
Page 16
RDP Specification Protocol Operation
variable length fields in the RDP segment header. The variable
length header fields are used to hold the sequence numbers of the
acknowledged out-of-sequence segments.
The type of acknowledgement used is simply a function of the
order in which segments arrive. Whenever possible, segments are
acknowledged using the cumulative acknowledgement segment. Only
out-of-sequence segments are acknowledged using the extended
acknowledgement option.
The user process, when initiating the connection, cannot
restrict the type of acknowledgement used on the connection. The
receiver may choose not to implement out-of-sequence
acknowledgements. On the other hand, the sender may choose to
ignore out-of-sequence acknowledgements.
3.4.4 Retransmission Timeout
Segments may be lost in transmission for two reasons: they
may be lost or damaged due to the effects of the lossy
transmission media; or they may be discarded by the receiving
RDP. The positive acknowledgement policy requires the receiver
to acknowledge a segment only when the segment has been correctly
received and accepted.
To detect missing segments, the sending RDP must use a
retransmission timer for each segment transmitted. The timer is
set to a value approximating the transmission time of the segment
in the network. When an acknowledgement is received for a
segment, the timer is cancelled for that segment. If the timer
expires before an acknowledgement is received for a segment, that
segment is retransmitted and the timer is restarted.
3.5 Flow Control and Window Management
RDP employs a simple flow control mechanism that is based on
the number of unacknowledged segments sent and the maximum
allowed number of outstanding (unacknowledged) segments. Each
RDP connection has an associated set of flow control parameters
that include the maximum number of outstanding segments for each
side of a connection. These parameters are specified when the
connection is opened with the Open request, with each side of the
connection specifying its own parameters. The parameters are
Page 17
RFC 908 July 1984
passed from one host to another in the initial connection
segments.
The values specified for these parameters should be based on
the amount and size of buffers that the RDP is willing to
allocate to a connection. The particular RDP implementation can
set the parameters to values that are optimal for its buffering
scheme. Once these parameters are set they remain unchanged
throughout the life of the connection.
RDP employs the concept of a sequence number window for
acceptable segment sequence numbers. The left edge of the window
is the number of the last in-sequence acknowledged sequence
number plus one. The right edge of the window is equal to the
left edge plus twice the allowed maximum number of outstanding
segments. The allowed maximum number of outstanding segments is
the number of segments the transmitting RDP software is allowed
to send without receiving any acknowledgement.
The flow control and window management parameters are used
as follows. The RDP module in the transmitting host sends
segments until it reaches the connection's segment limit
specified by the receiving process. Once this limit is reached,
the transmitting RDP module may only send a new segment for each
acknowledged segment.
When a received segment has a sequence number that falls
within the acceptance window, it is acknowledged. If the
sequence number is equal to the left-hand edge (i.e., it is the
next sequence number expected), the segment is acknowledged with
a cumulative acknowledgement (ACK). The acceptance window is
adjusted by adding one to the value of the edges. If the
sequence number is within the acceptance window but is out of
sequence, it is acknowledged with a non-cumulative
acknowledgement (EACK). The window is not adjusted, but the
receipt of the out-of-sequence segment is recorded.
When segments are acknowledged out of order, the
transmitting RDP module must not transmit beyond the acceptance
window. This could occur if one segment is not acknowledged but
all subsequent segments are received and acknowledged. This
condition will fix the left edge of the window at the sequence
number of the unacknowledged segment. As additional segments are
transmitted, the next segment to be sent will approach and
eventually overtake the right window edge. At this point all
transmission of new segments will cease until the unacknowledged
segment is acknowledged.
Page 18
RDP Specification Protocol Operation
3.6 User Interface
The user interface to RDP is implementation dependent and
may use system calls, function calls or some other mechanism.
The list of requests that follows is not intended to suggest a
particular implementation.
OPEN Request
Opens a connection. Parameters include type (active or
passive), local port, remote port, remote host address,
maximum segment size, maximum number of unacknowledged
segments, delivery mode (sequenced or non-sequenced). The
connection id, including any allocated port number, is
returned to the user.
SEND Request
Sends a user message. Parameters include connection
identifier, buffer address and data count.
RECEIVE Request
Receives a user message. Parameters include connection
identifier, buffer address and data count.
CLOSE Request
Closes a specified connection. The single parameter is the
connection identifier.
STATUS Request
Returns the status of a connection. The parameters include
the connection identifier and the address of the status
buffer.
Page 19
RFC 908 July 1984
3.7 Event Processing
This section describes one possible sequence for processing
events. It is not intended to suggest a particular
implementation, but any actual implementation should vary from
this description only in detail and not significantly in
substance. The following are the kinds of events that may occur:
USER REQUESTS
Open
Send
Receive
Close
Status
ARRIVING SEGMENT
Segment Arrives
TIMEOUTS
Retransmission Timeout
Close-Wait Timeout
User request processing always terminates with a return to
the caller, with a possible error indication. Error responses
are given as a character string. A delayed response is also
possible in some situations and is returned to the user by
whatever event or pseudo interrupt mechanism is available. The
term "signal" is used to refer to delayed responses.
Processing of arriving segments usually follows this general
sequence: the sequence number is checked for validity and, if
valid, the segment is queued and processed in sequence-number
order. For all events, unless a state change is specified, RDP
remains in the same state.
Page 20
RDP Specification Protocol Operation
3.7.1 User Request Events
The following scenarios demonstrate the processing of events
caused by the issuance of user requests:
Open Request
CLOSED STATE
Create a connection record
If none available
Return "Error - insufficient resources"
Endif
If passive Open
If local port not specified
Return "Error - local port not specified"
Endif
Generate SND.ISS
Set SND.NXT = SND.ISS + 1
SND.UNA = SND.ISS
Fill in SND.MAX, RMAX.BUF from Open parameters
Set State = LISTEN
Return
Endif
If active Open
If remote port not specified
Return "Error - remote port not specified"
Endif
Generate SND.ISS
Set SND.NXT = SND.ISS + 1
SND.UNA = SND.ISS
Fill in SND.MAX, RMAX.BUF from Open parameters
If local port not specified
Allocate a local port
Endif
Send <SEQ=SND.ISS><MAX=SND.MAX><MAXBUF=RMAX.BUF><SYN>
Set State = SYN-SENT
Return (local port, connection identifier)
Endif
Page 21
RFC 908 July 1984
LISTEN STATE
SYN-SENT STATE
SYN-RCVD STATE
OPEN STATE
CLOSE-WAIT STATE
Return "Error - connection already open"
Close Request
OPEN STATE
Send <SEQ=SND.NXT><RST>
Set State = CLOSE-WAIT
Start TIMWAIT Timer
Return
LISTEN STATE
Set State = CLOSED
Deallocate connection record
Return
SYN-RCVD STATE
SYN-SENT STATE
Send <SEQ=SND.NXT><RST>
Set State = CLOSED
Return
CLOSE-WAIT STATE
Return "Error - connection closing"
CLOSE STATE
Return "Error - connection not open"
Page 22
RDP Specification Protocol Operation
Receive Request
OPEN STATE
If Data is pending
Return with data
else
Return with "no data" indication
Endif
LISTEN STATE
SYN-RCVD STATE
SYN-SENT STATE
Return with "no data" indication
CLOSE STATE
CLOSE-WAIT STATE
Return "Error - connection not open"
Send Request
OPEN STATE
If SND.NXT < SND.UNA + SND.MAX
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK><Data>
Set SND.NXT = SND.NXT + 1
Return
else
Return "Error - insufficient resources to send data"
Endif
LISTEN STATE
SYN-RCVD STATE
SYN-SENT STATE
CLOSE STATE
CLOSE-WAIT STATE
Return "Error - connection not open"
Status Request
Return with:
Page 23
RFC 908 July 1984
State of connection (OPEN, LISTEN, etc.)
Number of segments unacknowledged
Number of segments received not given to user
Maximum segment size for the send side of the connection
Maximum segment size for the receive side of the connection
3.7.2 Segment Arrival Events
The following scenarios describe the processing of the event
caused by the arrival of a RDP segment from a remote host. The
assumption is made that the segment was addressed to the local
port associated with the connection record.
If State = CLOSED
If RST set
Discard segment
Return
Endif
If ACK or NUL set
Send <SEQ=SEG.ACK + 1><RST>
Discard segment
Return
else
Send <SEQ=0><RST><ACK=RCV.CUR><ACK>
Discard segment
Return
Endif
Endif
If State = CLOSE-WAIT
If RST set
Set State = CLOSED
Discard segment
Cancel TIMWAIT timer
Deallocate connection record
else
Discard segment
Endif
Return
Endif
Page 24
RDP Specification Protocol Operation
If State = LISTEN
If RST set
Discard the segment
Return
Endif
If ACK or NUL set
Send <SEQ=SEG.ACK + 1><RST>
Return
Endif
If SYN set
Set RCV.CUR = SEG.SEQ
RCV.IRS = SEG.SEQ
SND.MAX = SEG.MAX
SBUF.MAX = SEG.BMAX
Send <SEQ=SND.ISS><ACK=RCV.CUR><MAX=RCV.MAX><BUFMAX=RBUF.MAX>
<ACK><SYN>
Set State = SYN-RCVD
Return
Endif
If anything else (should never get here)
Discard segment
Return
Endif
Endif
If State = SYN-SENT
If ACK set
If RST clear and SEG.ACK != SND.ISS
Send <SEQ=SEG.ACK + 1><RST>
Endif
Discard segment; Return
Endif
If RST set
If ACK set
Signal "Connection Refused"
Set State = CLOSED
Deallocate connection record
Endif
Discard segment
Return
Endif
Page 25
RFC 908 July 1984
If SYN set
Set RCV.CUR = SEG.SEQ
RCV.IRS = SEG.SEQ
SND.MAX = SEG.MAX
RBUF.MAX = SEG.BMAX
If ACK set
Set SND.UNA = SEG.ACK
State = OPEN
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK>
else
Set State = SYN-RCVD
Send <SEQ=SND.ISS><ACK=RCV.CUR><MAX=RCV.MAX><BUFMAX=RBUF.MAX>
<SYN><ACK>
Endif
Return
Endif
If anything else
Discard segment
Return
Endif
Endif
If State = SYN-RCVD
If RCV.IRS < SEG.SEQ =< RCV.CUR + (RCV.MAX * 2)
Segment sequence number acceptable
else
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK>
Discard segment
Return
Endif
If RST set
If passive Open
Set State = LISTEN
else
Set State = CLOSED
Signal "Connection Refused"
Discard segment
Deallocate connection record
Endif
Return
Endif
Page 26
RDP Specification Protocol Operation
If SYN set
Send <SEQ=SEG.ACK + 1><RST>
Set State = CLOSED
Signal "Connection Reset"
Discard segment
Deallocate connection record
Return
Endif
If EACK set
Send <SEQ=SEG.ACK + 1><RST>
Discard segment
Return
Endif
If ACK set
If SEG.ACK = SND.ISS
Set State = OPEN
else
Send <SEQ=SEG.ACK + 1><RST>
Discard segment
Return
Endif
else
Discard segment
Return
Endif
If Data in segment or NUL set
If the received segment is in sequence
Copy the data (if any) to user buffers
Set RCV.CUR=SEG.SEQ
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK>
else
If out-of-sequence delivery permitted
Copy the data (if any) to user buffers
Endif
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK><EACK><RCVDSEQNO1>
...<RCVDSEQNOn>
Endif
Endif
Endif
Page 27
RFC 908 July 1984
If State = OPEN
If RCV.CUR < SEG.SEQ =< RCV.CUR + (RCV.MAX * 2)
Segment sequence number acceptable
else
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK>
Discard segment and return
Endif
If RST set
Set State = CLOSE-WAIT
Signal "Connection Reset"
Return
Endif
If NUL set
Set RCV.CUR=SEG.SEQ
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK>
Discard segment
Return
Endif
If SYN set
Send <SEQ=SEG.ACK + 1><RST>
Set State = CLOSED
Signal "Connection Reset"
Discard segment
Deallocate connection record
Return
Endif
If ACK set
If SND.UNA =< SEG.ACK < SND.NXT
Set SND.UNA = SEG.ACK
Flush acknowledged segments
Endif
Endif
If EACK set
Flush acknowledged segments
Endif
Page 28
RDP Specification Protocol Operation
If Data in segment
If the received segment is in sequence
Copy the data to user buffers
Set RCV.CUR=SEG.SEQ
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK>
else
If out-of-sequence delivery permitted
Copy the data to user buffers
Endif
Send <SEQ=SND.NXT><ACK=RCV.CUR><ACK><EACK><RCVDSEQNO1>
...<RCVDSEQNOn>
Endif
Endif
Endif
3.7.3 Timeout Events
Timeout events occur when a timer expires and signals the
RDP. Two types of timeout events can occur, as described below:
RETRANSMISSION TIMEOUTS
If timeout on segment at head of retransmission queue
Resend the segment at head of queue
Restart the retransmission timer for the segment
Requeue the segment on retransmission queue
Return
Endif
CLOSE-WAIT TIMEOUTS
Set State = CLOSED
Deallocate connection record
Return
Page 29
RFC 908 July 1984
Page 30
RDP Specification RDP Segments and Formats
CHAPTER 4
RDP Segments and Formats
The segments sent by the application layer are encapsulated
in headers by the transport, internet and network layers, as
follows:
+----------------+
| Network Access |
| Header |
+----------------+
| IP Header |
+----------------+
| RDP Header |
+----------------+
| D |
| A |
| T |
| A |
+----------------+
Segment Format
Figure 4
4.1 IP Header Format
When used in the internet environment, RDP segments are sent
using the version 4 IP header as described in RFC 791, "Internet
Protocol." The RDP protocol number is ??? (decimal). The time-
to-live field should be set to a reasonable value for the
network.
All other fields should be set as specified in RFC 791.
Page 31
RFC 908 July 1984
4.2 RDP Header Format
Every RDP segment is prefaced with an RDP header. The
format of the header is shown in Figure 5 below. The RDP header
is variable in length and its size is indicated by a field in a
fixed location within the header.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
|S|A|E|R|N| |Ver| Header |
0 |Y|C|A|S|U|0|No.| Length |
|N|K|K|T|L| | | |
+-+-+-+-+-+-+---+---------------+
1 | Source Port | Dest. Port |
+---------------+---------------+
2 | Data Length |
+---------------+---------------+
3 | |
+--- Sequence Number ---+
4 | |
+---------------+---------------+
5 | |
+--- Acknowledgement Number ---+
6 | |
+---------------+---------------+
7 | |
+--- Checksum ---+
8 | |
+---------------+---------------+
9 | Variable Header Area |
. .
. .
| |
+---------------+---------------+
RDP Header Format
Figure 5
Page 32
RDP Specification RDP Segments and Formats
4.2.1 RDP Header Fields
Control Flags
This 8-bit field occupies the first octet of word one in the
header. It is bit encoded with the following bits currently
defined:
Bit # Bit Name Description
0 SYN Establish connection and
synchronize sequence numbers.
1 ACK Acknowledge field significant.
2 EACK Non-cumulative (Extended) acknowledgement.
3 RST Reset the connection.
4 NUL This is a null (zero data length) segment.
5 Unused.
Note that the SYN and RST are sent as separate segments and
may not contain any data. The ACK may accompany any
message. The NUL segment must have a zero data length, but
may be accompanied by ACK and EACK information. The other
control bit is currently unused and is defined to be zero.
Version Number
This field occupies bits 6-7 of the first octet. It
contains the version number of the protocol described by
this document. Current value is one (1).
Header Length
The length of the RDP header in units of two (2) octets,
including this field. This field allows RDP to find the
start of the Data field, given a pointer to the head of the
segment. This field is 8 bits in length. For a segment
with no variable header section, the header length field
will have the value 9.
Source and Destination Ports
The Source and Destination Ports are used to identify the
processes in the two hosts that are communicating with each
other. The combination of the port identifiers with the
source and destination addresses in the network access
Page 33
RFC 908 July 1984
protocol header serves to fully qualify the connection and
constitutes the connection identifier. This permits RDP to
distinguish multiple connections between two hosts. Each
field is 8 bits in length, allowing port numbers from 0 to
255 (decimal).
Data Length
The length in octets of the data in this segment. The data
length does not include the RDP header. This field is 16
bits in length.
Sequence Number
The sequence number of this segment. This field is 32 bits
in length.
Acknowledgement Number
If the ACK bit is set in the header, this is the sequence
number of the segment that the sender of this segment last
received correctly and in sequence. Once a connection is
established this should always be sent. This field is 32
bits in length.
Checksum
This field is a 32-bit checksum of the segment header and
data. The algorithm description below includes two
variables, the checksum accumulator and the checksum
pointer. The checksum accumulator is an actual 32-bit
register in which the checksum is formed. The checksum
pointer is included for purposes of description, to
represent the operation of advancing through the data four
octets (32-bits) at a time. It need not be maintained in a
register by an implementation.
1) The checksum pointer is set to zero, to correspond to the
beginning of the area to be checksummed. The checksum
accumulator is also initialized to zero before beginning the
computation of the checksum.
2) The 32-bit memory word located at the address referenced
by the checksum pointer is added arithmetically to the
checksum accumulator. Any carry propagated out of the
checksum accumulator is ignored. The checksum field itself
is replaced with zeros when being added to the checksum
Page 34
RDP Specification RDP Segments and Formats
accumulator.
3) The checksum accumulator is rotated left one bit
position. The checksum pointer is advanced to correspond to
the address of the next 32-bit word in the segment.
4) Steps 2 and 3 are repeated until the entire segment has
been summed. If a segment contains a number of header and
data octets that is not an integral multiple of 4 octets,
the last octet is padded on the right with zeros to form a
32-bit quantity for computation purposes.
Variable Header Area
This area is used to transmit parameters for the SYN and
EACK segments.
Page 35
RFC 908 July 1984
4.3 SYN Segment
The SYN is used to establish a connection and synchronize
sequence numbers between two hosts. The SYN segment also
contains information to inform the remote host of the maximum
number of segments the local RDP is willing to accept and the
maximum segment size it can accept. The SYN may be combined with
an ACK in a segment but is never combined with user data.
4.3.1 SYN Segment Format
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
0 |1|0|0|0|0|0|0 1| Header Length |
+-+-+-+-+-+-+---+---------------+
1 | Source Port | Dest. Port |
+---------------+---------------+
2 | Data Length = 0 |
+---------------+---------------+
3 | |
+--- Sequence Number ---+
4 | |
+---------------+---------------+
5 | |
+--- Acknowledgement Number ---+
6 | |
+---------------+---------------+
7 | |
+--- Checksum ---+
8 | |
+---------------+---------------+
9 | Max. # of Outstanding Segments|
+---------------+---------------+
10 | Max. Segment Size |
+-------------------------------+
11 | Options Flag Field |
+---------------+---------------+
SYN Segment Format
Figure 6
Page 36
RDP Specification RDP Segments and Formats
4.3.2 SYN Segment Fields
Sequence Number
Contains the initial sequence number selected for this
connection.
Acknowledgement Number
This field is valid only if the ACK flag is set. In that
case, this field will contain the sequence number of the SYN
segment received from the other RDP.
Maximum Number of Outstanding Segments
The maximum number of segments that should be sent without
getting an acknowledgement. This is used by the receiver as
a means of flow control. The number is selected during
connection initiation and may not be changed later in the
life of the connection.
Maximum Segment Size
The maximum size segment in octets that the sender should
send. It informs the sender how big the receiver's buffers
are. The specified size includes the length of the IP
header, RDP header, and data. It does not include the
network access layer's header length.
Options Flag Field
This field of two octets contains a set of options flags
that specify the set of optional functions that are desired
for this connection. The flags are defined as follows:
Bit # Bit Name Description
0 SDM Sequenced delivery mode.
The sequenced delivery mode flag specifies whether delivery
of segments to the user is sequenced (delivered in
sequence-number order) or non-sequenced (delivered in
arrival order, regardless of sequence number). A value of 0
specifies non-sequenced delivery of segments, and a value of
1 specifies sequenced delivery.
Page 37
RFC 908 July 1984
4.4 ACK Segment
The ACK segment is used to acknowledge in-sequence segments.
It contains both the next send sequence number and the
acknowledgement sequence number in the RDP header. The ACK
segment may be sent as a separate segment, but it should be
combined with data whenever possible. Data segments must always
include the ACK bit and Acknowledgement Number field.
4.4.1 ACK Segment Format
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
0 |0|1|0|0|0|0|0 1| Header Length |
+-+-+-+-+-+-+---+---------------+
1 | Source Port | Dest. Port |
+---------------+---------------+
2 | Data Length |
+---------------+---------------+
3 | |
+--- Sequence Number ---+
4 | |
+---------------+---------------+
5 | |
+--- Acknowledgement Number ---+
6 | |
+---------------+---------------+
7 | |
+--- Checksum ---+
8 | |
+---------------+---------------+
| |
| Data |
. .
. .
+---------------+---------------+
ACK Segment Format
Figure 7
Page 38
RDP Specification RDP Segments and Formats
4.4.2 ACK Segment Fields
Data Length
A non-zero Data Length field indicates that there is data
present in the segment.
Sequence Number
The value of the Sequence Number field is advanced to the
next sequence number only if there is data present in the
segment. An ACK segment without data does not use sequence
number space.
Acknowledgement Number
The Acknowledgement Number field contains the sequence
number of the last segment received in sequential order.
Page 39
RFC 908 July 1984
4.5 Extended ACK Segment
The EACK segment is used to acknowledge segments received
out of sequence. It contains the sequence numbers of one or more
segments received with a correct checksum, but out of sequence.
The EACK is always combined with an ACK in the segment, giving
the sequence number of the last segment received in sequence.
The EACK segment may also include user data.
4.5.1 EACK Segment Format
The EACK segment has the format shown in Figure 8.
4.5.2 EACK Segment Fields
Data Length
A non-zero Data Length field indicates that there is data
present in the segment.
Sequence Number
The value of the Sequence Number field is advanced to the
next sequence number only if there is data present in the
segment. An EACK segment without data does not use sequence
number space.
Acknowledgement Number
The Acknowledgement Number field contains the sequence
number of the last segment received in sequential order.
Sequence # Received OK
Each entry is the sequence number of a segment that was
received with a correct checksum, but out of sequence.
Page 40
RDP Specification RDP Segments and Formats
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
0 |0|1|1|0|0|0|0 1| Header Length |
+-+-+-+-+-+-+---+---------------+
1 | Source Port | Dest. Port |
+---------------+---------------+
2 | Data Length |
+---------------+---------------+
3 | |
+--- Sequence Number ---|
4 | |
+---------------+---------------+
5 | |
+--- Acknowledgement Number ---+
6 | |
+---------------+---------------+
7 | |
+--- Checksum ---+
8 | |
+---------------+---------------+
9 | |
+--- Sequence # Received OK ---+
10 | |
+---------------+---------------+
11 | |
+--- Sequence # Received OK ---+
12 | |
+---------------+---------------+
: . :
: . :
: . :
+---------------+---------------+
| |
| Data |
| |
+---------------+---------------+
EACK Segment Format
Figure 8
Page 41
RFC 908 July 1984
4.6 RST Segment
The RST segment is used to close or reset a connection.
Upon receipt of an RST segment, the sender must stop sending and
must abort any unserviced requests. The RST is sent as a
separate segment and does not include any data.
4.6.1 RST Segment Format
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
0 |0|0|0|1|0|0|0 1| Header Length |
+-+-+-+-+-+-+---+---------------+
1 | Source Port | Dest. Port |
+---------------+---------------+
2 | Data Length = 0 |
+---------------+---------------+
3 | |
+--- Sequence Number ---+
4 | |
+---------------+---------------+
5 | |
+--- Acknowledgement Number ---+
6 | |
+---------------+---------------+
7 | |
+--- Checksum ---+
8 | |
+-------------------------------+
RST Segment Format
Figure 9
Page 42
RDP Specification RDP Segments and Formats
4.7 NUL Segment
The NUL segment is used to determine if the other side of a
connection is still active. When a NUL segment is received, an
RDP implementation must acknowledge the segment if a valid
connection exists and the segment sequence number falls within
the acceptance window. The segment is then discarded. The NUL
may be combined with an ACK in a segment but is never combined
with user data.
4.7.1 NUL segment format
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+---+---------------+
0 |0|0|0|0|1|0|0 1| Header Length |
+-+-+-+-+-+-+---+---------------+
1 | Source Port | Dest. Port |
+---------------+---------------+
2 | Data Length = 0 |
+---------------+---------------+
3 | |
+--- Sequence Number ---+
4 | |
+---------------+---------------+
5 | |
+--- Acknowledgement Number ---+
6 | |
+---------------+---------------+
7 | |
+--- Checksum ---+
8 | |
+-------------------------------+
NUL Segment Format
Figure 10
Page 43
RFC 908 July 1984
Page 44
RDP Specification Examples of Operation
CHAPTER 5
Examples of Operation
5.1 Connection Establishment
This is an example of a connection being established between
Host A and Host B. Host B has done a passive Open and is in
LISTEN state. Host A does an active Open to establish the
connection.
Host A Host B
Time State State
1. CLOSED LISTEN
2. SYN-SENT <SEQ=100><SYN> --->
3. <--- <SEQ=200><ACK=100><SYN,ACK>
SYN-RCVD
4. OPEN <SEQ=101><ACK=200> ---> OPEN
5. <SEQ=101><ACK=200><Data> --->
6. <--- <SEQ=201><ACK=101>
Page 45
RFC 908 July 1984
5.2 Simultaneous Connection Establishment
This is an example of two hosts trying to establishing
connections to each other at the same time. Host A sends a SYN
request to Host B at the same time Host B sends a SYN request to
Host A.
Host A Host B
Time State State
1. CLOSED CLOSED
2. SYN-SENT <SEQ=100><SYN> --->
<--- <SEQ=200><SYN> SYN-SENT
3. SYN-RCVD SYN-RCVD
<SEQ=100><ACK=200><SYN,ACK> --->
<--- <SEQ=200><ACK=100><SYN,ACK>
4. OPEN OPEN
Page 46
RDP Specification Examples of Operation
5.3 Lost Segments
This is an example of what happens when a segment is lost.
It shows how segments can be acknowledged out of sequence and
that only the missing segment need be retransmitted. Note that
in this and the following examples "EA" stands for "Out of
Sequence Acknowledgement."
Time Host A Host B
1. <SEQ=100><ACK=200><Data> --->
2. <--- <SEQ=201><ACK=100>
3. <SEQ=101><ACK=200><Data> (segment lost)
4.
5. <SEQ=102><ACK=200><Data> --->
6. <-- <SEQ=201><ACK=100><EA=102>
7. <SEQ=103><ACK=200><Data> --->
8. <--- <SEQ=201><ACK=100>
<EA=102,103>
9. <SEQ=101><ACK=200><Data> --->
10. <--- <SEQ=201><ACK=103>
11. <SEQ=104><ACK=200><Data> --->
12. <--- <SEQ=201><ACK=104>
Page 47
RFC 908 July 1984
5.4 Segments Received Out of Order
This an example of segments received out of order. It
further illustrates the use of acknowledging segments out of
order to prevent needless retransmissions.
Time Host A Host B
1. <SEQ=100><ACK=200><Data> --->
2. <--- <SEQ=201><ACK=100>
3. <SEQ=101><ACK=200><Data> (delayed)
4.
5. <SEQ=102><ACK=200><Data> --->
6. <--- <SEQ=201><ACK=100><EA=102>
7. <SEQ=103><ACK=200><Data> --->
---> (delayed segment 101 arrives)
8. <--- <SEQ=201><ACK=103>
9. <SEQ=104><ACK=200><Data> --->
10. <--- <SEQ=201><ACK=104>
Page 48
RDP Specification Examples of Operation
5.5 Communication Over Long Delay Path
This is an example of a data transfer over a long delay
path. In this example, Host A is permitted to have as many as
five unacknowledged segments. The example shows that it is not
necessary to wait for an acknowledgement in order to send
additional data.
Time Host A Host B
1. <SEQ=100><ACK=200><Data> -1->
2. <SEQ=101><ACK=200><Data> -2->
3. <SEQ=102><ACK=200><Data> -3->
-1-> (received)
4. <-4- <SEQ=201><ACK=100>
5. <SEQ=103><ACK=200><Data> -5->
-2-> (received)
6. <-6- <SEQ=201><ACK=101>
7. <SEQ=104><ACK=200><Data> -7->
-3-> (received)
8. <-8- <SEQ=201><ACK=102>
(received) <-4-
9. <SEQ=105><ACK=200><Data> -9->
-5-> (received)
10. <-10- <SEQ=201><ACK=103>
(received) <-6-
11. <SEQ=106><ACK=200><Data> -11->
-7-> (received)
12. <-12- <SEQ=201><ACK=104>
(received) <-8-
13. -9-> (received)
14. <-13- <SEQ=201><ACK=105>
(received) <-10-
15. -11-> (received)
16. <-14- <SEQ=201><ACK=106>
(received) <-12-
17. (received) <-13-
18. (received) <-14-
Page 49
RFC 908 July 1984
5.6 Communication Over Long Delay Path With Lost Segments
This is an example of communication over a long delay path
with a lost segment. It shows that by acknowledging segments out
of sequence, only the lost segment need be retransmitted.
Time Host A Host B
1. <SEQ=100><ACK=200><Data> -1->
2. <SEQ=101><ACK=200><Data> -2->
3. <SEQ=102><ACK=200><Data> -3->
-1-> (received)
4. <-4- <SEQ=201><ACK=100>
5. <SEQ=103><ACK=200><Data> (segment lost)
-2-> (received)
6. <-5- <SEQ=201><ACK=101>
7. <SEQ=104><ACK=200><Data> -6->
-3-> (received)
8. <-7- <SEQ=201><ACK=102>
(received) <-4-
9. <SEQ=105><ACK=200><Data> -8->
10.
(received) <-5-
11. <SEQ=106><ACK=200><Data> -10->
-6-> (received)
12. <-11- <SEQ=201><ACK=102><EA=104>
(received) <-7-
-8-> (received)
13. <-12- <SEQ=201><ACK=102><EA=104,105>
-10-> (received)
14. <-13- <SEQ=201><ACK=102><EA=104-106>
(received) <-11-
15. <SEQ=103><ACK=200><Data> -14->
(received) <-12-
16. (received) <-13-
-14-> (received)
17. <-15- <SEQ=201><ACK=106>
18.
19. (received) <-15-
Page 50
RDP Specification Examples of Operation
5.7 Detecting a Half-Open Connection on Crash Recovery
This is an example of a host detecting a half-open
connection due to the crash and subsequent restart of the host.
In this example, Host A crashes during a communication session,
then recovers and tries to reopen the connection. During the
reopen attempt, it discovers that a half-open connection still
exists and it then resets the other side. Both sides were in the
OPEN state prior to the crash.
Host A Host B
Time
1. OPEN OPEN
(crash!) <--- <SEQ=200><ACK=100><ACK>
2. CLOSED OPEN
(recover)
3. SYN-SENT OPEN
<SEQ=400><SYN> ---> (?)
4. SYN-SENT OPEN
(!) <--- <SEQ=200><ACK=100><ACK>
5. SYN-SENT OPEN
<SEQ=101><RST> ---> (abort)
6. SYN-SENT CLOSED
7. SYN-SENT <SEQ=400><SYN> --->
Page 51
RFC 908 July 1984
5.8 Detecting a Half-Open Connection from the Active Side
This is another example of detecting a half-open connection
due to the crash and restart of a host involved in a connection.
In this example, host A again crashes and restarts. Host B is
still active and tries to send data to host A. Since host A has
no knowledge of the connection, it rejects the data with an RST
segment, causing host B to reset the connection.
Host A Host B
Time
1. (crash!) OPEN
2. CLOSED <--- <SEQ=200><ACK=100><Data> OPEN
3. CLOSED <SEQ=101><RST> ---> (abort)
4. CLOSED CLOSED
Page 52
RDP Specification Examples of Operation
APPENDIX A
Implementing a Minimal RDP
It is not necessary to implement the entire RDP
specification to be able to use RDP. For simple applications
such as a loader, where size of the protocol module may be
important, a subset of RDP may be used. For example, an
implementation of RDP for loading may employ the following
restrictions:
o Only one connection and connection record is supported.
This is the connection used to load the device.
o A single, well-known port is used as the loader port.
Allocable ports are not implemented.
o Only the passive Open request is implemented. Active Opens
are not supported.
o The sequenced delivery option is not supported. Messages
arriving out of order are delivered in the order they
arrive.
o If efficiency is less important than protocol size, the
extended acknowledgement feature need not be supported.
Page 53
RFC 908 July 1984
INDEX
ACK.......................................... 16, 33, 34, 38
ACK segment format....................................... 38
acknowledgement number field......... 16, 34, 37, 38, 39, 40
byte-stream protocols................................. 4, 14
checksum................................................. 16
checksum field........................................... 34
Close request............................................ 13
Closed state.......................................... 9, 10
CLOSEWAIT................................................ 12
Close-Wait state................................. 10, 11, 13
CLOSE-WAIT timeouts...................................... 29
connection, closing of............................... 13, 42
connection, establishment of...................... 8, 11, 45
connection identifier................................. 7, 33
connection management..................................... 7
connection record..................................... 9, 11
connection state diagram................................. 10
connection states......................................... 8
control flags field...................................... 33
cumulative acknowledgement............................... 16
data communication....................................... 14
data length field................................ 34, 39, 40
datagrams................................................. 6
debugging.............................................. 1, 3
dumping................................................... 3
EACK......................................... 16, 33, 35, 40
EACK segment format...................................... 40
event processing......................................... 20
extended acknowledgement................................. 16
flow control............................................. 17
half-open connection, detection of............... 14, 51, 52
initial sequence number....................... 9, 11, 12, 15
internet protocols........................................ 5
IP................................................ 6, 15, 31
IP header............................................ 31, 37
Listen state................................... 8, 9, 10, 45
loading................................................ 1, 3
maximum segment size..................... 11, 12, 13, 15, 37
maximum unacknowledged segments.............. 11, 12, 17, 37
message fragmentation.................................... 14
non-cumulative acknowledgement........................... 16
Page 54
RDP Specification Examples of Operation
NUL.................................................. 33, 43
NUL segment format....................................... 43
Open request.......................................... 8, 17
Open request, active................................... 8, 9
Open request, passive.................................. 8, 9
Open state....................................... 10, 11, 45
options flag field....................................... 37
out-of-sequence acknowledgement.................. 12, 16, 18
ports................................................. 7, 33
ports, well-known......................................... 8
positive acknowledgement............................. 15, 16
RBUF.MAX................................................. 13
RCV.CUR.................................................. 12
RCVDSEQNO................................................ 12
RCV.IRS.................................................. 12
RCV.MAX.................................................. 12
RDP connection........................................... 14
RDP header................................... 14, 16, 32, 37
RDP header length........................................ 33
RDP segment format....................................... 31
reliable communication................................... 15
retransmission of segments....................... 15, 16, 17
retransmission timeout............................... 17, 29
RST.................................................. 33, 42
RST segment.......................................... 13, 52
RST segment format....................................... 42
SBUF.MAX................................................. 12
SDM...................................................... 37
SEG.ACK.................................................. 13
SEG.BMAX................................................. 13
SEG.MAX.................................................. 13
segment arrival events............................... 20, 24
segments................................................. 14
SEG.SEQ.................................................. 13
Send request......................................... 14, 15
sequence number...................................... 12, 15
sequence number acceptance window........................ 18
sequence number field........................ 34, 37, 39, 40
sequenced delivery................................. 3, 4, 37
sequential acknowledgement................................ 4
SND.ISS.................................................. 12
SND.MAX.................................................. 12
SND.NXT.................................................. 11
SND.UNA.................................................. 12
STATE.................................................... 11
SYN.................................. 12, 13, 15, 33, 35, 36
SYN segment........................................... 9, 36
Page 55
RFC 908 July 1984
Syn-Rcvd state........................................ 9, 10
Syn-Sent state........................................ 9, 10
TCP................................................... 4, 14
three-way handshake....................................... 4
user request events.................................. 20, 21
version number field..................................... 33
Page 56
RDP Specification Examples of Operation
Page 57
Reliable Data Protocol
RFC TOTAL SIZE: 97646 bytes
PUBLICATION DATE: Wednesday, September 23rd, 1992
LEGAL RIGHTS: The IETF Trust (see BCP 78)
|
