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 [2].  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



[1]  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.

[2]  Postel, J. (ed.), "DOD Standard Internet Protocol," Defense
     Advanced Research Projects Agency, Information Processing
     Techniques Office, RFC 760, IEN 128, January 1980.

[3]  Feinler, E. and J. Postel, ARPANET Protocol Handbook, Network
     Information Center, SRI International, Menlo Park, CA,
     January 1978.

[4]  Dalal, Y. and C. Sunshine, "Connection Management in Transport
     Protocols," Computer Networks, Vol. 2, No. 6, pp. 454-473,
     December 1978.