As per Relevance of the word acknowledge, we have this rfc below:
Network Working Group C.
Request for Comments: 1151 BBN Systems and
Updates: RFC 908 R.
BBN Communications Corp
April 1990
Version 2 of the Reliable Data Protocol (RDP
Status of this
This RFC suggests several updates to the specification of
Reliable Data Protocol (RDP) in RFC-908 based on experience with
protocol. This revised version of the protocol is experimental
Distribution of this memo is unlimited
Experiments in 1986 and 1987 turned up some ambiguities and
with the RDP specification. At the time, it was hoped that
authors might find the time to revise the entire RDP specification
fix these problems, however given the limited demand for
implementations, the authors were never able to justify the
involved in revising the spec. This document lists the changes
we believe are appropriate to make to RDP version 1.
Readers are expected to be familiar with RFC-908.
Changes To The Protocol
There are three changes to the protocol header: the
algorithm has been changed, the port size increased, and the
number incremented. The new header format is shown in Figure 1.
The major discovery during the testing of the protocol is that
of computing the the RDP checksum proved surprisingly variable;
performance was more heavily affected by the host's
representation than anticipated. Optimized checksum
on two comparable hardware bases gave performance that differed by
factor of five. Since the speed of the checksum is a key factor
the performance of the protocol itself, this variation caused
noticeable difference in throughput
The wide variation in performance on comparable machines was felt
be undesirable, so the checksum has been changed. RDP now uses
16-bit TCP checksum, which is specified on page 16 of RFC-793.
Partridge & Hinden [Page 1]
RFC 1151 RDP - Version 2 April 1990
The 8-bit port size is probably too small to support a large range
applications. Accordingly, the port size is now 16-bits.
numbers less than 1024 are reserved for well-defined applications
Allocable ports begin at port number 1024.
Finally, because the checksum and port size have been changed,
version number has been increased to 2.
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 |
+---------------+---------------+
2 | Destination Port |
+---------------+---------------+
3 | Data Length |
+---------------+---------------+
4 | |
+--- Sequence Number ---+
5 | |
+---------------+---------------+
6 | |
+--- Acknowledgement Number ---+
7 | |
+---------------+---------------+
8 | Checksum |
+---------------+---------------+
9 | Variable Header Area |
. .
. .
| |
+---------------+---------------+
RDP Header
Figure 1
Minor Errors and
Some ambiguities and minor errors have been found in RFC-908.
are corrected in this section
The value of the state variable, SND.UNA is treated inconsistently
the pseudo-code on pages 21-29. On page 12, SND.UNA is defined
Partridge & Hinden [Page 2]
RFC 1151 RDP - Version 2 April 1990
"the sequence number of the oldest unacknowledged segment", and
page 21 it is appropriately set to the initial sequence number
the connection is opened. But on page 28, when an acknowledgement
received, SND.UNA is set to SEG.ACK, the sequence number
acknowledged, instead of SEG.ACK+1. A similar inconsistency
on page 26. The proper fix is to always set SND.UNA to SEG.ACK+1.
The pseudo-code on page 25 for the SYN-SENT state is incorrect.
first few lines cause all packets with the ACK bit set to
discarded, but later lines test the ACK bit. The test for the
bit should be placed after all the other tests. Also note that
the ACK bit is set, a RST segment is sent to reset the remote peer
but the local peer is left half-open. There is a similar problem
the SYN-RCVD state. The local peer should deallocate the
record and close
On page 24, the pseudo-code indicates that if non-data packets
received in the CLOSED state, a RST segment with SEG.ACK set
RCV.CUR should be sent. RCV.CUR is not defined in the CLOSED state
SEG.ACK should be set to SEG.SEG
There is some inconsistency about how to handle a RST packet in
CLOSE-WAIT state. On page 24, the pseudo-code shows that a
should cause the connection state to become CLOSED. Text on page 13
and the state diagram on page 10 suggest the connection state
stay in CLOSE-WAIT. The implementation should stay in CLOSE-WAIT
On page 29, the pseudo-code for the OPEN state suggests that if
data packet is received in sequence, the acknowledgement
should not contain EACKs. This is misleading. Implementations
include EACKs in the acknowledgement
On page 18, it is possible to interpret the right edge as
either inside or outside the window. This results in a one
difference in the window size. The proper interpretation is that
right edge is outside the window. In other words, the right edge
the first sequence number that cannot be sent or received and
total window size is 2*X, where X is the maximum number
outstanding segments
One final problem is that RDP's flow control scheme does not
the receiver to close the sender's window. As a result, if
receiver acknowledges segments when they are received the sender
easily send more data than the receiver is prepared to buffer.
solution to this problem (suggested by members of the End-2-
Research Group) is to only acknowledge a segment after it has
delivered to the application. This scheme, however, has not
tested
Partridge & Hinden [Page 3]
RFC 1151 RDP - Version 2 April 1990
Security
Security issues are not addressed in this memo
Authors'
Craig
Bolt Beranek and Newman Inc
50 Moulton
Cambridge, MA 02138
Phone: (617) 873-2459
EMail: craig@BBN.
Robert
Bolt Beranek and Newman Inc
50 Moulton
Cambridge, MA 02238
Phone: (617) 873-3757
Email: HINDEN@BBN.
Partridge & Hinden [Page 4]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
