Embedded Web Server for the CR16
Limited memory space does not permit the queuing of received segments, and so our window size
is effectively one segment. However, since we expend every effort to keep pace with the
incoming data, we advertise a larger window size, and never adjust it. This effectively
precludes a window going silly on us. On the receive side, TCP checks the peers window size
before transmitting data. Should the peers window be too small, TCP will delay transmissions
until such time that the peers window opens.
Support for the zero window probe
This is another tool utilized to augment the sliding window flow control mechanism. If we are
currently sending data to a peer and the peer advertises a window size of zero (for some reason
it cannot currently accept any more data), we should periodically transmit probe segments to
discover if the connection is still viable or has been prematurely aborted. If zero window
probing is not supported, the connection may hang forever in the unfortunate event that the
peers ACK segment that re-opens the window is lost (not an improbable event).
This implementation does not queue received segments. Rather, upon reception every segment
is immediately passed to the Application. We therefore never advertise a Window size of zero.
Probe segments, if received are ACKd. If the peer advertises a zero window, data transmission
is suspended, and probe segments are issued every second. Should the window remain closed
beyond a timeout interval, a reset is issued and the connection is closed.
Support for Timeout with Retransmission
Integral to TCP is the retransmission of segments that have not been Acknowledged (ACKd) in
a timely fashion. The RFC mandates the implementation of an algorithm developed by Jacobson
for computing the smoothed round-trip-time (RTT), and an algorithm by Karn for computing the
retransmission timeout ("RTO"). Additionally, all implementations must include exponential
back off for successive RTO values for the same segment.
Sorry - this implementation deals with retransmission in a slightly less expensive fashion. Each
transmitted segment is queued. Actually, the segment data itself is not queued, since this
would require enormous amounts of RAM. Only the segments relevant parameters are queued
(See Figure 9.). This allows for many more segments than the limited RAM would otherwise
allow. Upon creation, each segment is timestamped with the current OS time. When the TCP
has sent all available segments, it periodically updates and checks the timer field of every
unACKd segment on the queue. If any or all of the queued segments awaiting acknowledgment
timeout, they will be retransmitted. If a segment times out a second time, a reset is sent to
the peer and the TCP closes.
The RFC does briefly mention the fact that in small-host implementations (such as ours),
segment queuing is often precluded due to limited buffer space. They remind us that this
omission may be expected to adversely affect TCP throughput, since the loss of a single
segment causes all later segments to appear to be "out of sequence". Noted.