Bugs in CPC/IP's TCP layer
CPC/IP's TCP layer is, sadly, not perfect. Here are the
know bugs. Please tell me
about any other bugs you discover! Please distinguish between
functional and non-functional bugs, and give as much information
as possible so I can reproduce the problem. And if you know of
or have access to some sort of TCP test suite, I'd be very interested...
Functional bugs
None of these are catastrophic, but...
-
There's no 2*MSL timeout; the TCP goes straight from TIME-WAIT to CLOSED
(so old segments could in principle cause trouble).
-
No check is made that the segment sent by the peer doesn't exceed
the receive window (so the app just has to lump it).
-
Simultaneous connections are not allowed (so two telnets
connecting to each other at exactly the same time will fail).
-
Bad ACKs in SYN-RECEIVED do not cause a connection reset.
-
It's not possible to make a passive open go active (so can't
go tcp_open after a tcp_listen).
Non-functional bugs
These merely make things less efficient than they could be.
-
No attention is paid to the peer's receive window (so in particular
if the peer sets this to zero CPC/IP just keeps trying every
retransmission timeout).
-
Segments partially containing old data are merely ACKed
(to coax the peer into sending just new data); any new data
is discarded.
-
Data and/or FIN received in SYN-SENT is ignored (the peer is
expected to resend it when only its SYN is ACKed).
-
Data waiting for transmission is only sent when the ESTABLISHED
state has been reached (it's not sent in segments sent in the SYN-SENT
or SYN-RECEIVED state).
-
The RTT is not measured; the retransmission timeout is
fixed at 3 seconds.
-
There's no support for urgent data.
-
CPC/IP doesn't wait for 2*MSL after booting to ensure
old segments have died off.
-
There's no protection against being left in FIN-WAIT-2 forever.
Nor is there any protection against retransmitting forever.
Not bugs
CPC/IP supports the following; not all stacks do.
-
Half-closes (closing the transmit direction but still being
able to receive until such time as the peer closes its
transmit direction too).
-
Concatenation of remaining data with a FIN.
-
Not suddenly deciding to resend old data for no apparent reason.
Oh, and CPC/IP will send an ACK before passing received
data to the app; this typically allows serial transfer
and handling of received data to be done in parallel.
Mark RISON,
<mrison@hotmail.com>,
2001-06-03
Thanks to Franck ARNAUD for hosting these pages.