Reliable Data Protocol (RDP)
TAGS: RDPReliable Data Protocol

Reliable Data Protocol (RDP)

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 for 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.

General Description

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 list of requirements for such a transport protocol:

  • 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 acknowledgment and retransmission mechanism is a necessary component of the protocol.
  • Since loading and dumping of memory images over the internet involve the bulk transfer of large amounts of data over a lossy network with potentially long delays, it is necessary that the protocol moves 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.
  • 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.
  • 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.
  • 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:

  • 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.
  • 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. 
  • TCP  provides sequenced delivery of data to the application.   If the application does not require such sequenced delivery, a large number 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.
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 acknowledgments.

11.11 sale, global festival, good price, coupon code

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:

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.

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.

Protocol Operation

Protocol Service Objectives
The RDP protocol has the following goals:
  • RDP will provide a full-duplex communications channel between the two ports of each transport connection.
  • 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.
  • 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.
  • RDP  will optionally provide sequenced delivery of segments. Sequenced delivery of segments must be specified when the connection is established.
  • RDP will acknowledge segments received out of sequence, as they arrive.   This will free up resources on the sending side.

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.

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.

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.

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 acknowledgment of segment receipt,  and timeout and retransmission of missing segments.

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 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 acknowledgment.

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 acknowledgment (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 acknowledgment (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.


Online Outlets for Suits


Books you may interested

Books on TCP/IP Books on TCP/IP  Books on TCP/IP Books on TCP/IP Books on TCP/IP Books on TCP/IP    


Leave a Reply

Your email address will not be published. Required fields are marked *