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.
Events that occur: User Calls OPEN SEND RECEIVE CLOSE ABORT STATUS Arriving Segments SEGMENT ARRIVES Timeouts USER TIMEOUT RETRANSMISSION TIMEOUT TIME-WAIT TIMEOUT
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.