Re: [colorforth] TCP State Engine

["John R. Strohm" <strohm@xxxxxxxxxxx>]

"Albert van der Horst" <albert@xxxxxxxxxxxxxxxxxx> said:
> On Wed, 14 Apr 2004, Samuel A. Falvo II wrote:
> > On Wednesday 14 April 2004 09:57 am, howerd.oakford@xxxxxxxxxxxx wrote:
> > While I agree that a TCP implementation can be reduced compared to its
> > more generalized implementation in Linux, for example, you *cannot* get
> > rid of sliding windows (even if it is just a window of one packet),
> > retries, and packet re-ordering.  These things are there because of the
> > very nature of IP itself.  To simplify TCP any further, you need either
> > a reliable datagram service, such as AX.25 (or, for that matter, any
> > other variant of X.25), or you need to very tightly control the
> > electrical parameters under which your network is operating to ensure
> > pristine data delivery.  I won't get into the schizophrenia behind the
> > horror that is X.25, or the veritable Cthulu that is AX.25.  And I
> > certainly won't get into the routing messes that happen all-too-often
> > once the average IP packet leaves your local network and enters the
> > global switching fabric.
>
> All this sounds horrible. What could we simplify if we use only the
> network hardware to communicate between two Forth boxes?

Not that much, when you get right down to it.

No matter what you do, down where the electrons (or photons) meet the
conducting media (or fiber), there exists some probability greater than zero
that any given packet will be damaged or destroyed.  In order to get
reliable end-to-end operation, the protocols in between have to deal with
damaged, destroyed, or even duplicate packets.  Most of the complexity in
the total protocol stack that we collectively refer to as "TCP/IP" comes
from that requirement.

Packets may be damaged.  At the least, you need error detection and
retransmission.  If you have lots of bandwidth (network or processing or
both) to spare, you can do error correction.

Packets may be dropped entirely.  You'd like to detect this, and retransmit
the dropped packets.

Depending on how you handle retransmission of damaged or dropped packets,
you might even see duplicated packets.  (Imagine what happens if a packet
goes one way and arrives intact, but the acknowledgement for that packet,
that goes the other way, gets damaged or dropped.)


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com