joshua@athertn.Atherton.COM (Flame Bait) (09/28/89)
Madness takes it toll....
I'm looking at the RDP description (RFC908) with an eye towards implementing
it on top of email, instead of IP packets. I chose it over VMTP (RFC1045)
because it seems simpler. The RDP description is about half as long
as the VMTP description, and the RDP description contains very simple and
short descriptions of the data structures and algorithms used. VMTP did
not seem to have these.
Do have some questions about the protocol:
Are there any known bugs in RDP as described in RFC 908?
What is the difference between a closed connection, and a connection
which does not have a connection record at all? It seems to me that
these are the same.
Why can a packet not contain data and a RST (end of connection) flag?
On a more general note, RDP only allows 256 ports and 4 versions. These
limits seem a little low to me. (They won't apply to my protocol though,
since it will have port names, and any number of versions. I'm mapping
fields in the RDP header into lines in an email header:
X-REP-Source: source-port-name
X-REP-Destination: destination-port-name
X-REP-Version: 0
and so on...)
BTW, the name for this project is REP, Reliable Email based Protocol,
which is also short for REPTILE, which should describe its speed. :-)
Joshua Levy
-------- Quote: "Remember: No matter how obnoxious it gets,
Addresses: you CANNOT execute a device!" -- Peter Franks
joshua@atherton.com
{decwrl|sun|hpda}!athertn!joshua work:(408)734-9822 home:(415)968-3718craig@NNSC.NSF.NET (Craig Partridge) (09/28/89)
Joshua:
I will pass the question of whether it makes sense to implement RDP
over e-mail and focus simply on your questions about the spec.
Yes there are known bugs in the RDP protocol as described in
RFC 908. The list is appended. Given the recent interest in
RDP, it may be time to actually sit down and generate the spec
for RDP version 2.
My recollection is there is no distinction between a CLOSED connection
and one without a connection record.
256 ports is much too low -- RDP version 2 would allow 16-bit
ports. It also uses the TCP checksum because the RDP checksum
proved very sensitive to byte order (as a result, RDP would run
4 or 5 times slower on machines with the wrong byte order).
Another problem is that RDP doesn't have a windowing scheme that
ensures the the receiver and sender stay in sync. In particular,
there's now way for the receiver to tell the sender that while
yes it has received the data, it doesn't want any more quite
yet. The best suggestion I've heard so far is from Van Jacobson,
which is for the receiver to delay the ack until it has actually
processed the data received.
Craig
RDP Error List
Minor Errors and Ambiguities
Some ambiguities and minor errors have been found in RFC-908.
They are corrected in this section.
The value of the state variable, SND.UNA is treated inconsistently
in the pseudo-code on pages 21-29. On page 12, SND.UNA is defined
as "the sequence number of the oldest unacknowledged segment",
and on page 21 it is appropriately set to the initial sequence
number when the connection is opened. But on page 28, when an
acknowledgement is received, SND.UNA is set to SEG.ACK, the
sequence number being acknowledged, instead of SEG.ACK+1. A
similar inconsistency occurs 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.
The first few lines cause all packets with the ACK bit set to be
discarded, but later lines test the ACK bit. The test for the ACK
bit should be placed after all the other tests. Also note that if
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 in
the SYN-RCVD state. The local peer should deallocate the connection
record and close.
On page 24, the pseudo-code indicates that if non-data packets are
received in the CLOSED state, a RST segment with SEG.ACK set to
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
the CLOSE-WAIT state. On page 24, the pseudo-code shows that a
RST should cause the connection state to become CLOSED. Text on
page 13 and the state diagram on page 10 suggest the connection
state should stay in CLOSE-WAIT. The implementation should stay
in CLOSE-WAIT.
On page 29, the pseudo-code for the OPEN state suggests that if a
data packet is received in sequence, the acknowledgement packet
should not contain EACKs. This is misleading. Implementations
may include EACKs in the acknowledgement.