The processing depicted in this section is an example of one possible
implementation. Other implementations may have slightly different
processing sequences, but they should differ from those in this
section only in detail, not in substance.
The activity of the TCP can be characterized as responding to events.
The events that occur can be cast into three categories: user calls,
arriving segments, and timeouts. This section describes the
processing the TCP does in response to each of the events. In many
cases the processing required depends on the state of the connection.
The model of the TCP/user interface is that user commands receive an
immediate return and possibly a delayed response via an event or
pseudo interrupt. In the following descriptions, the term "signal"
means cause a delayed response.
Error responses are given as character strings. For example, user
commands referencing connections that do not exist receive "error:
connection not open".
Please note in the following that all arithmetic on sequence numbers,
acknowledgment numbers, windows, et cetera, is modulo 2**32 the size
of the sequence number space. Also note that "=<" means less than or
equal to (modulo 2**32).
A natural way to think about processing incoming segments is to
imagine that they are first tested for proper sequence number (i.e.,
that their contents lie in the range of the expected "receive window"
in the sequence number space) and then that they are generally queued
and processed in sequence number order.
When a segment overlaps other already received segments we reconstruct
the segment to contain just the new data, and adjust the header fields
to be consistent.
Note that if no state change is mentioned the TCP stays in the same
state.
