buffer. If the EOL flag is not set, subsequent SENDs will appear to be part of the same letter. If the URGENT flag is set, segments resulting from this call will have the urgent pointer set to indicate that some of the data associated with this call is urgent. This facility, for example, can be used to simulate "break" signals from terminals or error or completion codes from I/O devices. The semantics of this signal to the receiving process are unspecified. The receiving TCP will signal the urgent condition to the receiving process as long as the urgent pointer indicates that data preceding the urgent pointer has not been consumed by the receiving process. The purpose of urgent is to stimulate the receiver to accept some urgent data and to indicate to the receiver when all the currently known urgent data has been received. The number of times the sending user's TCP signals urgent will not necessarily be equal to the number of times the receiving user will be notified of the presence of urgent data. If no foreign socket was specified in the OPEN, but the connection is established (e.g., because a LISTENing connection has become specific due to a foreign segment arriving for the local socket), then the designated buffer is sent to the implied foreign socket. In general, users who make use of OPEN with an unspecified foreign socket can make use of SEND without ever explicitly knowing the foreign socket address. However, if a SEND is attempted before the foreign socket becomes specified, an error will be returned. Users can use the STATUS call to determine the status of the connection. In some implementations the TCP may notify the user when an unspecified socket is bound. If a timeout is specified, then the current timeout for this connection is changed to the new one. In the simplest implementation, SEND would not return control to the sending process until either the transmission was complete or the timeout had been exceeded. However, this simple method is both subject to deadlocks (for example, both sides of the connection might try to do SENDs before doing any RECEIVEs) and offers poor performance, so it is not recommended. A more sophisticated implementation would return immediately to allow the process to run concurrently with network I/O, and, furthermore, to allow multiple SENDs to be in progress.
Multiple SENDs are served in first come, first served order, so the TCP will queue those it cannot service immediately. We have implicitly assumed an asynchronous user interface in which a SEND later elicits some kind of SIGNAL or pseudo-interrupt from the serving TCP. An alternative is to return a response immediately. For instance, SENDs might return immediate local acknowledgment, even if the segment sent had not been acknowledged by the distant TCP. We could optimistically assume eventual success. If we are wrong, the connection will close anyway due to the timeout. In implementations of this kind (synchronous), there will still be some asynchronous signals, but these will deal with the connection itself, and not with specific segments or letters. NOTA BENE: In order for the process to distinguish among error or success indications for different SENDs, it might be appropriate for the buffer address to be returned along with the coded response to the SEND request. TCP-to-user signals are discussed below, indicating the information which should be returned to the calling process. Receive Format: RECEIVE (local connection name, buffer address, byte count) This command allocates a receiving buffer associated with the specified connection. If no OPEN precedes this command or the calling process is not authorized to use this connection, an error is returned. In the simplest implementation, control would not return to the calling program until either the buffer was filled, or some error occurred, but this scheme is highly subject to deadlocks. A more sophisticated implementation would permit several RECEIVEs to be outstanding at once. These would be filled as, segments arrive. This strategy permits increased throughput at the cost of a more elaborate scheme (possibly asynchronous) to notify the calling program that a letter has been received or a buffer filled. If insufficient buffer space is given to reassemble a complete letter, the EOL flag will not be set in the response to the RECEIVE. The buffer will be filled with as much data as it can hold. The last buffer required to hold the letter is returned with EOL signaled.
The remaining parts of a partly delivered letter will be placed in buffers as they are made available via successive RECEIVEs. If a number of RECEIVEs are outstanding, they may be filled with parts of a single long letter or with at most one letter each. The return codes associated with each RECEIVE will indicate what is contained in the buffer. If a buffer size was given in the OPEN call, then all buffers presented in RECEIVE calls must be of exactly that size, or an error indication will be returned. The URGENT flag will be set only if the receiving user has previously been informed via a TCP-to-user signal, that urgent data is waiting. The receiving user should thus be in "read-fast" mode. If the URGENT flag is on, additional urgent data remains. If the URGENT flag is off, this call to RECEIVE has returned all the urgent data, and the user may now leave "read-fast" mode. To distinguish among several outstanding RECEIVEs and to take care of the case that a letter is smaller than the buffer supplied, the return code is accompanied by both a buffer pointer and a byte count indicating the actual length of the letter received. Alternative implementations of RECEIVE might have the TCP allocate buffer storage, or the TCP might share a ring buffer with the user. Variations of this kind will produce obvious variation in user interface to the TCP. Close Format: CLOSE(local connection name) This command causes the connection specified to be closed. If the connection is not open or the calling process is not authorized to use this connection, an error is returned. Closing connections is intended to be a graceful operation in the sense that outstanding SENDs will be transmitted (and retransmitted), as flow control permits, until all have been serviced. Thus, it should be acceptable to make several SEND calls, followed by a CLOSE, and expect all the data to be sent to the destination. It should also be clear that users should continue to RECEIVE on CLOSING connections, since the other side may be trying to transmit the last of its data. Thus, CLOSE means "I have no more to send" but does not mean "I will not receive any more." It may happen (if the user level protocol is not well thought out) that the closing side is unable to get rid
of all its data before timing out. In this event, CLOSE turns into ABORT, and the closing TCP gives up. The user may CLOSE the connection at any time on his own initiative, or in response to various prompts from the TCP (e.g., remote close executed, transmission timeout exceeded, destination inaccessible). Because closing a connection requires communication with the foreign TCP, connections may remain in the closing state for a short time. Attempts to reopen the connection before the TCP replies to the CLOSE command will result in error responses. Close also implies end of letter. Status Format: STATUS(local connection name) This is an implementation dependent user command and could be excluded without adverse effect. Information returned would typically come from the TCB associated with the connection. This command returns a data block containing the following information: local socket, foreign socket, local connection name, receive window, send window, connection state, number of buffers awaiting acknowledgment, number of buffers pending receipt (including partial ones), receive buffer size, urgent state, precedence, security/compartment, and default transmission timeout. Depending on the state of the connection, or on the implementation itself, some of this information may not be available or meaningful. If the calling process is not authorized to use this connection, an error is returned. This prevents unauthorized processes from gaining information about a connection.
Abort Format: ABORT (local connection name) This command causes all pending SENDs and RECEIVES to be aborted, the TCB to be removed, and a special RESET message to be sent to the TCP on the other side of the connection. Depending on the implementation, users may receive abort indications for each outstanding SEND or RECEIVE, or may simply receive an ABORT-acknowledgment. TCP-to-User Messages It is assumed that the operating system environment provides a means for the TCP to asynchronously signal the user program. When the TCP does signal a user program, certain information is passed to the user. Often in the specification the information will be an error message. In other cases there will be information relating to the completion of processing a SEND or RECEIVE or other user call. The following information is provided: Local Connection Name Always Response String Always Buffer Address Send & Receive Byte count (counts bytes received) Receive End-of-Letter flag Receive End-of-Urgent flag Receive TCP/Network Interface The TCP calls on a lower level protocol module to actually send and receive information over a network. One case is that of the ARPA internetwork system where the lower level module is the Internet Protocol . In most cases the following simple interface would be adequate.
The following two calls satisfy the requirements for the TCP to internet protocol module communication: SEND (dest, TOS, TTL, BufPTR, len, Id, DF, options => result) where: dest = destination address TOS = type of service TTL = time to live BufPTR = buffer pointer len = length of buffer Id = Identifier DF = Don't Fragment options = internet option data result = response OK = datagram sent ok Error = error in arguments or local network error Note that the precedence is included in the TOS and the security/compartment is passed as an option. RECV (BufPTR => result, source, dest, prot, TOS, len) where: BufPTR = buffer pointer result = response OK = datagram received ok Error = error in arguments source = source address dest = destination address prot = protocol TOS = type of service options = internet option data len = length of buffer Note that the precedence is in the TOS, and the security/compartment is an option. When the TCP sends a segment, it executes the SEND call supplying all the arguments. The internet protocol module, on receiving this call, checks the arguments and prepares and sends the message. If the arguments are good and the segment is accepted by the local network, the call returns successfully. If either the arguments are bad, or the segment is not accepted by the local network, the call returns unsuccessfully. On unsuccessful returns, a reasonable report should be made as to the cause of the
problem, but the details of such reports are up to individual implementations. When a segment arrives at the internet protocol module from the local network, either there is a pending RECV call from TCP or there is not. In the first case, the pending call is satisfied by passing the information from the segment to the TCP. In the second case, the TCP is notified of a pending segment. The notification of a TCP may be via a pseudo interrupt or similar mechanism, as appropriate in the particular operating system environment of the implementation. A TCP's RECV call may then either be immediately satisfied by a pending segment, or the call may be pending until a segment arrives. We note that the Internet Protocol provides arguments for a type of service and for a time to live. TCP uses the following settings for these parameters: Type of Service = Precedence: none, Package: stream, Reliability: higher, Preference: speed, Speed: higher; or 00011111. Time to Live = one minute, or 00111100. Note that the assumed maximum segment lifetime is two minutes. Here we explicitly ask that a segment be destroyed if it cannot be delivered by the internet system within one minute.
3.9. Event Processing 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 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. 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.
OPEN Call CLOSED STATE (i.e., TCB does not exist) Create a new transmission control block (TCB) to hold connection state information. Fill in local socket identifier, foreign socket, precedence, security/compartment, and user timeout information. Verify the security and precedence requested are allowed for this user, if not return "error: precedence not allowed" or "error: security/compartment not allowed." If active and the foreign socket is unspecified, return "error: foreign socket unspecified"; if active and the foreign socket is specified, issue a SYN segment. An initial send sequence number (ISS) is selected and the TCP receive buffer size is selected (if applicable). A SYN segment of the form <SEQ=ISS><CTL=SYN> is sent (this may include the buffer size option if applicable). Set SND.UNA to ISS, SND.NXT to ISS+1, SND.LBB to ISS+1, enter SYN-SENT state, and return. If the caller does not have access to the local socket specified, return "error: connection illegal for this process". If there is no room to create a new connection, return "error: insufficient resources". LISTEN STATE SYN-SENT STATE SYN-RECEIVED STATE ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE TIME-WAIT STATE CLOSE-WAIT STATE CLOSING STATE Return "error: connection already exists".
SEND Call CLOSED STATE (i.e., TCB does not exist) If the user should no have access to such a connection, then return "error: connection illegal for this process". Otherwise, return "error: connection does not exist". LISTEN STATE If the foreign socket is specified, then change the connection from passive to active, select an ISS, and select the receive buffer size. Send a SYN segment, set SND.UNA to ISS, SND.NXT to ISS+1 and SND.LBB to ISS+1. Enter SYN-SENT state. Data associated with SEND may be sent with SYN segment or queued for transmission after entering ESTABLISHED state. The urgent bit if requested in the command should be sent with the first data segment sent as a result of this command. If there is no room to queue the request, respond with "error: insufficient resources". If Foreign socket was not specified, then return "error: foreign socket unspecified". SYN-SENT STATE Queue for processing after the connection is ESTABLISHED. Typically, nothing can be sent yet, anyway, because the send window has not yet been set by the other side. If no space, return "error: insufficient resources". SYN-RECEIVED STATE Queue for later processing after entering ESTABLISHED state. If no space to queue, respond with "error: insufficient resources". ESTABLISHED STATE Segmentize the buffer, send or queue it for output, with a piggybacked acknowledgment (acknowledgment value = RCV.NXT) with the data. If there is insufficient space to remember this buffer, simply return "error: insufficient resources". If remote buffer size is not one octet, and, if this is the end of a letter, do the following end-of-letter/buffer-size adjustment processing:
if EOL = 0 then SND.NXT <- SEG.SEQ + SEG.LEN if EOL = 1 then While SND.LBB < SEG.SEQ + SEG.LEN Do SND.LBB <- SND.LBB + SND.BS End SND.NXT <- SND.LBB If the urgent flag is set, then SND.UP <- SND.NXT-1 and set the urgent pointer in the outgoing segment. FIN-WAIT-1 STATE FIN-WAIT-2 STATE TIME-WAIT STATE Return "error: connection closing" and do not service request. CLOSE-WAIT STATE Segmentize any text to be sent and queue for output. If there is insufficient space to remember the SEND, return "error: insufficient resources" CLOSING STATE Respond with "error: connection closing"
RECEIVE Call CLOSED STATE (i.e., TCB does not exist) If the user should no have access to such a connection, return "error: connection illegal for this process". Otherwise return "error: connection does not exist". LISTEN STATE SYN-SENT STATE SYN-RECEIVED STATE Queue for processing after entering ESTABLISHED state. If there is no room to queue this request, respond with "error: insufficient resources". ESTABLISHED STATE If insufficient incoming segments are queued to satisfy the request, queue the request. If there is no queue space to remember the RECEIVE, respond with "error: insufficient resources". Reassemble queued incoming segments into receive buffer and return to user. Mark "end of letter" (EOL) if this is the case. If RCV.UP is in advance of the data currently being passed to the user notify the user of the presence of urgent data. When the TCP takes responsibility for delivering data to the user that fact must be communicated to the sender via an acknowledgment. The formation of such an acknowledgment is described below in the discussion of processing an incoming segment. FIN-WAIT-1 STATE FIN-WAIT-2 STATE Reassemble and return a letter, or as much as will fit, in the user buffer. Queue the request if it cannot be serviced immediately.
TIME-WAIT STATE CLOSE-WAIT STATE Since the remote side has already sent FIN, RECEIVEs must be satisfied by text already reassembled, but not yet delivered to the user. If no reassembled segment text is awaiting delivery, the RECEIVE should get a "error: connection closing" response. Otherwise, any remaining text can be used to satisfy the RECEIVE. CLOSING STATE Return "error: connection closing"
CLOSE Call CLOSED STATE (i.e., TCB does not exist) If the user should no have access to such a connection, return "error: connection illegal for this process". Otherwise, return "error: connection does not exist". LISTEN STATE Any outstanding RECEIVEs should be returned with "error: closing" responses. Delete TCB, return "ok". SYN-SENT STATE Delete the TCB and return "error: closing" responses to any queued SENDs, or RECEIVEs. SYN-RECEIVED STATE Queue for processing after entering ESTABLISHED state or segmentize and send FIN segment. If the latter, enter FIN-WAIT-1 state. ESTABLISHED STATE Queue this until all preceding SENDs have been segmentized, then form a FIN segment and send it. In any case, enter FIN-WAIT-1 state. FIN-WAIT-1 STATE FIN-WAIT-2 STATE Strictly speaking, this is an error and should receive a "error: connection closing" response. An "ok" response would be acceptable, too, as long as a second FIN is not emitted (the first FIN may be retransmitted though).
TIME-WAIT STATE Strictly speaking, this is an error and should receive a "error: connection closing" response. An "ok" response would be acceptable, too. However, since the FIN has been sent and acknowledged, nothing should be sent (or retransmitted). CLOSE-WAIT STATE Queue this request until all preceding SENDs have been segmentized; then send a FIN segment, enter CLOSING state. CLOSING STATE Respond with "error: connection closing"
ABORT Call CLOSED STATE (i.e., TCB does not exist) If the user should no have access to such a connection, return "error: connection illegal for this process". Otherwise return "error: connection does not exist". LISTEN STATE Any outstanding RECEIVEs should be returned with "error: connection reset" responses. Delete TCB, return "ok". SYN-SENT STATE Delete the TCB and return "reset" responses to any queued SENDs, or RECEIVEs. SYN-RECEIVED STATE Send a RST of the form: <SEQ=SND.NXT><ACK=RCV.NXT><CTL=RST,ACK> and return any unprocessed SENDs, or RECEIVEs with "reset" code, delete the TCB. ESTABLISHED STATE Send a reset segment: <SEQ=SND.NXT><ACK=RCV.NXT><CTL=RST,ACK> All queued SENDs and RECEIVEs should be given "reset" responses; all segments queued for transmission (except for the RST formed above) or retransmission should be flushed, delete the TCB.
FIN-WAIT-1 STATE FIN-WAIT-2 STATE A reset segment (RST) should be formed and sent: <SEQ=SND.NXT><ACK=RCV.NXT><CTL=RST,ACK> Outstanding SENDs, RECEIVEs, CLOSEs, and/or segments queued for retransmission, or segmentizing, should be flushed, with "connection reset" notification to the user, delete the TCB. TIME-WAIT STATE Respond with "ok" and delete the TCB. CLOSE-WAIT STATE Flush any pending SENDs and RECEIVEs, returning "connection reset" responses for them. Form and send a RST segment: <SEQ=SND.NXT><ACK=RCV.NXT><CTL=RST,ACK> Flush all segment queues and delete the TCB. CLOSING STATE Respond with "ok" and delete the TCB; flush any remaining segment queues. If a CLOSE command is still pending, respond "error: connection reset".
STATUS Call CLOSED STATE (i.e., TCB does not exist) If the user should no have access to such a connection, return "error: connection illegal for this process". Otherwise return "error: connection does not exist". LISTEN STATE Return "state = LISTEN", and the TCB pointer. SYN-SENT STATE Return "state = SYN-SENT", and the TCB pointer. SYN-RECEIVED STATE Return "state = SYN-RECEIVED", and the TCB pointer. ESTABLISHED STATE Return "state = ESTABLISHED", and the TCB pointer. FIN-WAIT-1 STATE Return "state = FIN-WAIT-1", and the TCB pointer. FIN-WAIT-2 STATE Return "state = FIN-WAIT-2", and the TCB pointer. TIME-WAIT STATE Return "state = TIME-WAIT and the TCB pointer. CLOSE-WAIT STATE Return "state = CLOSE-WAIT", and the TCB pointer. CLOSING STATE Return "state = CLOSING", and the TCB pointer.
SEGMENT ARRIVES If the state is CLOSED (i.e., TCB does not exist) then all data in the incoming segment is discarded. An incoming segment containing a RST is discarded. An incoming segment not containing a RST causes a RST to be sent in response. The acknowledgment and sequence field values are selected to make the reset sequence acceptable to the TCP that sent the offending segment. If the ACK bit is off, sequence number zero is used, <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK> If the ACK bit is on, <SEQ=SEG.ACK><CTL=RST> Return. If the state is LISTEN then first check for an ACK Any acknowledgment is bad if it arrives on a connection still in the LISTEN state. An acceptable reset segment should be formed for any arriving ACK-bearing segment, except another RST. The RST should be formatted as follows: <SEQ=SEG.ACK><CTL=RST> Return. An incoming RST should be ignored. Return. if there was no ACK then check for a SYN If the SYN bit is set, check the security. If the security/compartment on the incoming segment does not exactly match the security/compartment in the TCB then send a reset and return. If the SEG.PRC is less than the TCB.PRC then send a reset and return. If the SEG.PRC is greater than the TCB.PRC then set TCB.PRC<-SEG.PRC. Now RCV.NXT and RCV.LBB are set to SEG.SEQ+1, IRS is set to SEG.SEQ and any other control or text should be queued for processing later. ISS should be selected and a SYN segment sent of the form:
<SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK> SND.NXT and SND.LBB are set to ISS+1 and SND.UNA to ISS. The connection state should be changed to SYN-RECEIVED. Note that any other incoming control or data (combined with SYN) will be processed in the SYN-RECEIVED state, but processing of SYN and ACK should not be repeated. If the listen was not fully specified (i.e., the foreign socket was not fully specified), then the unspecified fields should be filled in now. if there was no SYN but there was other text or control Any other control or text-bearing segment (not containing SYN) must have an ACK and thus would be discarded by the ACK processing. An incoming RST segment could not be valid, since it could not have been sent in response to anything sent by this incarnation of the connection. So you are unlikely to get here, but if you do, drop the segment, and return. If the state is SYN-SENT then first check for an ACK If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, or the security/compartment in the segment does not exactly match the security/compartment in the TCB, or the precedence in the segment is less than the precedence in the TCB, send a reset <SEQ=SEG.ACK><CTL=RST> and discard the segment. Return. If SND.UNA =< SEG.ACK =< SND.NXT and the security/compartment and precedence are acceptable then the ACK is acceptable. SND.UNA should be advanced to equal SEG.ACK, and any segments on the retransmission queue which are thereby acknowledged should be removed. if the ACK is ok (or there is no ACK), check the RST bit If the RST bit is set then signal the user "error: connection reset", enter CLOSED state, drop the segment, delete TCB, and return. if the ACK is ok (or there is no ACK) and it was not a RST, check the SYN bit
If the SYN bit is on and the security/compartment and precedence are acceptable then, RCV.NXT and RCV.LBB are set to SEG.SEQ+1, IRS is set to SEG.SEQ. If SND.UNA > ISS (our SYN has been ACKed), change the connection state to ESTABLISHED, otherwise enter SYN-RECEIVED. In any case, form an ACK segment: <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> and send it. Data or controls which were queued for transmission may be included. If SEG.PRC is greater than TCB.PRC set TCB.PRC<-SEG.PRC. If there are other controls or text in the segment then continue processing at the fifth step below where the URG bit is checked, otherwise return.
Otherwise, first check sequence number SYN-RECEIVED STATE ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE TIME-WAIT STATE CLOSE-WAIT STATE CLOSING STATE Segments are processed in sequence. Initial tests on arrival are used to discard old duplicates, but further processing is done in SEG.SEQ order. If a segment's contents straddle the boundary between old and new, only the new parts should be processed. There are four cases for the acceptability test for an incoming segment: Segment Receive Test Length Window ------- ------- ------------------------------------------- 0 0 SEG.SEQ = RCV.NXT 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND >0 0 not acceptable >0 >0 RCV.NXT < SEG.SEQ+SEG.LEN =< RCV.NXT+RCV.WND Note that the test above guarantees that the last sequence number used by the segment lies in the receive-window. If the RCV.WND is zero, no segments will be acceptable, but special allowance should be made to accept valid ACKs, URGs and RSTs. If an incoming segment is not acceptable, an acknowledgment should be sent in reply: <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> If the incoming segment is unacceptable, drop it and return.
second check security and precedence If the security/compartment and precedence in the segment do not exactly match the security/compartment and precedence in the TCB then form a reset and return. Note this check is placed following the sequence check to prevent a segment from an old connection between these parts with a different security or precedence from causing an abort of the current connection. third check the ACK field, SYN-RECEIVED STATE If the RST bit is off and SND.UNA < SEG.ACK =< SND.NXT then set SND.UNA <- SEG.ACK, remove any acknowledged segments from the retransmission queue, and enter ESTABLISHED state. If the segment acknowledgment is not acceptable, form a reset segment, <SEQ=SEG.ACK><CTL=RST> and send it, unless the incoming segment is an RST (or there is no ACK), in which case, it should be discarded, then return. ESTABLISHED STATE If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <- SEG.ACK. Any segments on the retransmission queue which are thereby entirely acknowledged are removed. Users should receive positive acknowledgments for buffers which have been SENT and fully acknowledged (i.e., SEND buffer should be returned with "ok" response). If the ACK is a duplicate, it can be ignored. If the segment passes the sequence number and acknowledgment number tests, the send window should be updated. If SND.WL =< SEG.SEQ, set SND.WND <- SEG.WND and set SND.WL <- SEG.SEQ. If the remote buffer size is not one, then the end-of-letter/buffer-size adjustment to sequence numbers may have an effect on the next expected sequence number to be acknowledged. It is possible that the remote TCP will acknowledge with a SEG.ACK equal to a sequence number of an
octet that was skipped over at the end of a letter. This a mild error on the remote TCPs part, but not cause for alarm. FIN-WAIT-1 STATE FIN-WAIT-2 STATE In addition to the processing for the ESTABLISHED state, if the retransmission queue is empty, the user's CLOSE can be acknowledged ("ok") but do not delete the TCB. TIME-WAIT STATE The only thing that can arrive in this state is a retransmission of the remote FIN. Acknowledge it, and restart the 2 MSL timeout. CLOSE-WAIT STATE Do the same processing as for the ESTABLISHED state. CLOSING STATE If the ACK acknowledges our FIN then delete the TCB (enter the CLOSED state), otherwise ignore the segment. fourth check the RST bit, SYN-RECEIVED STATE If the RST bit is set then, if the segment has passed sequence and acknowledgment tests, it is valid. If this connection was initiated with a passive OPEN (i.e., came from the LISTEN state), then return this connection to LISTEN state. The user need not be informed. If this connection was initiated with an active OPEN (i.e., came from SYN-SENT state) then the connection was refused, signal the user "connection refused". In either case, all segments on the retransmission queue should be removed.
ESTABLISHED FIN-WAIT-1 FIN-WAIT-2 CLOSE-WAIT CLOSING STATE If the RST bit is set then, any outstanding RECEIVEs and SEND should receive "reset" responses. All segment queues should be flushed. Users should also receive an unsolicited general "connection reset" signal. Enter the CLOSED state, delete the TCB, and return. TIME-WAIT Enter the CLOSED state, delete the TCB, and return. fifth, check the SYN bit, SYN-RECEIVED ESTABLISHED STATE If the SYN bit is set, check the segment sequence number against the receive window. The segment sequence number must be in the receive window; if not, ignore the segment. If the SYN is on and SEG.SEQ = IRS then everything is ok and no action is needed; but if they are not equal, there is an error and a reset must be sent. If a reset must be sent it is formed as follows: <SEQ=SEG.ACK><CTL=RST> The connection must be aborted as if a RST had been received. FIN-WAIT STATE-1 FIN-WAIT STATE-2 TIME-WAIT STATE CLOSE-WAIT STATE CLOSING STATE This case should not occur, since a duplicate of the SYN which started the current connection incarnation will have been filtered in the SEG.SEQ processing. Other SYN's will have been rejected by this test as well (see SYN processing for ESTABLISHED state).
sixth, check the URG bit, ESTABLISHED STATE FIN-WAIT-1 STATE FIN-WAIT-2 STATE If the URG bit is set, RCV.UP <- max(RCV.UP,SEG.UP), and signal the user that the remote side has urgent data if the urgent pointer (RCV.UP) is in advance of the data consumed. If the user has already been signaled (or is still in the "urgent mode") for this continuous sequence of urgent data, do not signal the user again. TIME-WAIT STATE CLOSE-WAIT STATE CLOSING This should not occur, since a FIN has been received from the remote side. Ignore the URG. seventh, process the segment text, ESTABLISHED STATE Once in the ESTABLISHED state, it is possible to deliver segment text to user RECEIVE buffers. Text from segments can be moved into buffers until either the buffer is full or the segment is empty. If the segment empties and carries an EOL flag, then the user is informed, when the buffer is returned, that an EOL has been received. If buffer size is not one octet, then do the following end-of-letter/buffer-size adjustment processing: if EOL = 0 then RCV.NXT <- SEG.SEQ + SEG.LEN if EOL = 1 then While RCV.LBB < SEG.SEQ+SEG.LEN Do RCV.LBB <- RCV.LBB + RCV.BS End RCV.NXT <- RCV.LBB When the TCP takes responsibility for delivering the data to the user it must also acknowledge the receipt of the data. Send an acknowledgment of the form:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> This acknowledgment should be piggybacked on a segment being transmitted if possible without incurring undue delay. FIN-WAIT-1 STATE FIN-WAIT-2 STATE If there are outstanding RECEIVEs, they should be satisfied, if possible, with the text of this segment; remaining text should be queued for further processing. If a RECEIVE is satisfied, the user should be notified, with "end-of-letter" (EOL) signal, if appropriate. TIME-WAIT STATE CLOSE-WAIT STATE This should not occur, since a FIN has been received from the remote side. Ignore the segment text. eighth, check the FIN bit, Send an acknowledgment for the FIN. Signal the user "connection closing", and return any pending RECEIVEs with same message. Note that FIN implies EOL for any segment text not yet delivered to the user. If the current state is ESTABLISHED, enter the CLOSE-WAIT state. If the current state is FIN-WAIT-1, enter the CLOSING state. If the current state is FIN-WAIT-2, enter the TIME-WAIT state. and return.
USER TIMEOUT For any state if the user timeout expires, flush all queues, signal the user "error: connection aborted due to user timeout" in general and for any outstanding calls, delete the TCB, and return. RETRANSMISSION TIMEOUT For any state if the retransmission timeout expires on a segment in the retransmission queue, send the segment at the front of the retransmission queue again, reinitialize the retransmission timer, and return.
GLOSSARY 1822 BBN Report 1822, "The Specification of the Interconnection of a Host and an IMP". The specification of interface between a host and the ARPANET. ACK A control bit (acknowledge) occupying no sequence space, which indicates that the acknowledgment field of this segment specifies the next sequence number the sender of this segment is expecting to receive, hence acknowledging receipt of all previous sequence numbers. ARPANET message The unit of transmission between a host and an IMP in the ARPANET. The maximum size is about 1012 octets (8096 bits). ARPANET packet A unit of transmission used internally in the ARPANET between IMPs. The maximum size is about 126 octets (1008 bits). buffer size An option (buffer size) used to state the receive data buffer size of the sender of this option. May only be sent in a segment that also carries a SYN. connection A logical communication path identified by a pair of sockets. datagram A message sent in a packet switched computer communications network. Destination Address The destination address, usually the network and host identifiers. EOL A control bit (End of Letter) occupying no sequence space, indicating that this segment ends a logical letter with the last data octet in the segment. If this end of letter causes a less than full buffer to be released to the user and the connection buffer size is not one octet then the end-of-letter/buffer-size adjustment to the receive sequence number must be made.
FIN A control bit (finis) occupying one sequence number, which indicates that the sender will send no more data or control occupying sequence space. fragment A portion of a logical unit of data, in particular an internet fragment is a portion of an internet datagram. FTP A file transfer protocol. header Control information at the beginning of a message, segment, fragment, packet or block of data. host A computer. In particular a source or destination of messages from the point of view of the communication network. Identification An Internet Protocol field. This identifying value assigned by the sender aids in assembling the fragments of a datagram. IMP The Interface Message Processor, the packet switch of the ARPANET. internet address A source or destination address specific to the host level. internet datagram The unit of data exchanged between an internet module and the higher level protocol together with the internet header. internet fragment A portion of the data of an internet datagram with an internet header. IP Internet Protocol. IRS The Initial Receive Sequence number. The first sequence number used by the sender on a connection.
ISN The Initial Sequence Number. The first sequence number used on a connection, (either ISS or IRS). Selected on a clock based procedure. ISS The Initial Send Sequence number. The first sequence number used by the sender on a connection. leader Control information at the beginning of a message or block of data. In particular, in the ARPANET, the control information on an ARPANET message at the host-IMP interface. left sequence This is the next sequence number to be acknowledged by the data receiving TCP (or the lowest currently unacknowledged sequence number) and is sometimes referred to as the left edge of the send window. letter A logical unit of data, in particular the logical unit of data transmitted between processes via TCP. local packet The unit of transmission within a local network. module An implementation, usually in software, of a protocol or other procedure. MSL Maximum Segment Lifetime, the time a TCP segment can exist in the internetwork system. Arbitrarily defined to be 2 minutes. octet An eight bit byte. Options An Option field may contain several options, and each option may be several octets in length. The options are used primarily in testing situations; for example, to carry timestamps. Both the Internet Protocol and TCP provide for options fields. packet A package of data with a header which may or may not be
logically complete. More often a physical packaging than a logical packaging of data. port The portion of a socket that specifies which logical input or output channel of a process is associated with the data. process A program in execution. A source or destination of data from the point of view of the TCP or other host-to-host protocol. PSN A Packet Switched Network. For example, the ARPANET. RCV.BS receive buffer size, the remote buffer size RCV.LBB receive last buffer beginning RCV.NXT receive next sequence number RCV.UP receive urgent pointer RCV.WND receive window receive last buffer beginning This is the sequence number of the first octet of the most recent buffer. This value is use in calculating the next sequence number when a segment contains an end of letter indication. receive next sequence number This is the next sequence number the local TCP is expecting to receive. receive window This represents the sequence numbers the local (receiving) TCP is willing to receive. Thus, the local TCP considers that segments overlapping the range RCV.NXT to RCV.NXT + RCV.WND - 1 carry acceptable data or control. Segments containing sequence numbers entirely outside of this range are considered duplicates and discarded.
RST A control bit (reset), occupying no sequence space, indicating that the receiver should delete the connection without further interaction. The receiver can determine, based on the sequence number and acknowledgment fields of the incoming segment, whether it should honor the reset command or ignore it. In no case does receipt of a segment containing RST give rise to a RST in response. RTP Real Time Protocol: A host-to-host protocol for communication of time critical information. Rubber EOL An end of letter (EOL) requiring a sequence number adjustment to align the beginning of the next letter on a buffer boundary. SEG.ACK segment acknowledgment SEG.LEN segment length SEG.PRC segment precedence value SEG.SEQ segment sequence SEG.UP segment urgent pointer field SEG.WND segment window field segment A logical unit of data, in particular a TCP segment is the unit of data transfered between a pair of TCP modules. segment acknowledgment The sequence number in the acknowledgment field of the arriving segment. segment length The amount of sequence number space occupied by a segment, including any controls which occupy sequence space.
segment sequence The number in the sequence field of the arriving segment. send last buffer beginning This is the sequence number of the first octet of the most recent buffer. This value is used in calculating the next sequence number when a segment contains an end of letter indication. send sequence This is the next sequence number the local (sending) TCP will use on the connection. It is initially selected from an initial sequence number curve (ISN) and is incremented for each octet of data or sequenced control transmitted. send window This represents the sequence numbers which the remote (receiving) TCP is willing to receive. It is the value of the window field specified in segments from the remote (data receiving) TCP. The range of sequence numbers which may be emitted by a TCP lies between SND.NXT and SND.UNA + SND.WND - 1. SND.BS send buffer size, the local buffer size SND.LBB send last buffer beginning SND.NXT send sequence SND.UNA left sequence SND.UP send urgent pointer SND.WL send sequence number at last window update SND.WND send window socket An address which specifically includes a port identifier, that is, the concatenation of an Internet Address with a TCP port.
Source Address The source address, usually the network and host identifiers. SYN A control bit in the incoming segment, occupying one sequence number, used at the initiation of a connection, to indicate where the sequence numbering will start. TCB Transmission control block, the data structure that records the state of a connection. TCB.PRC The precedence of the connection. TCP Transmission Control Protocol: A host-to-host protocol for reliable communication in internetwork environments. TOS Type of Service, an Internet Protocol field. Type of Service An Internet Protocol field which indicates the type of service for this internet fragment. URG A control bit (urgent), occupying no sequence space, used to indicate that the receiving user should be notified to do urgent processing as long as there is data to be consumed with sequence numbers less than the value indicated in the urgent pointer. urgent pointer A control field meaningful only when the URG bit is on. This field communicates the value of the urgent pointer which indicates the data octet associated with the sending user's urgent call.
REFERENCES  Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication," IEEE Transactions on Communications, Vol. COM-22, No. 5, pp 637-648, May 1974.  Postel, J. (ed.), "DOD Standard Internet Protocol," Defense Advanced Research Projects Agency, Information Processing Techniques Office, RFC 760, IEN 128, January 1980.  Feinler, E. and J. Postel, ARPANET Protocol Handbook, Network Information Center, SRI International, Menlo Park, CA, January 1978.  Dalal, Y. and C. Sunshine, "Connection Management in Transport Protocols," Computer Networks, Vol. 2, No. 6, pp. 454-473, December 1978.