rfc675.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,653 行 · 第 1/5 页

   use the connection specified. Depending upon the implementation of
   the TCP, the source network and TCP identifiers will either be
   supplied by the TCP or by the processes that serve it [e.g. the



Cerf, Dalal & Sunshine                                          [Page 6]

RFC 675              Specification of Internet TCP         December 1974


   program which interfaces the TCP to its packet switch or the packet
   switch itself]. These considerations are the result of concern about
   security, to the extent that no TCP be able to masquerade as another
   one, and so on. Similarly, no process can masquerade as another
   without the collusion of the TCP.

   If no foreign socket is specified [i.e. the foreign socket parameter
   is 0 or not present], then this constitutes a LISTENING local socket
   which can accept communication from any foreign socket. Provision is
   also made for partial specification of foreign sockets as described
   in section 2.2.

   If the specified connection is already OPEN, an error is returned,
   otherwise a full-duplex transmission control block [TCB] is created
   and partially filled in with data from the OPEN command parameters.
   The TCB format is described in more detail in section 4.2.2.

   No network traffic is generated by the OPEN command. The first SEND
   or INTERRUPT by the local user or the foreign user will cause the TCP
   to synchronize the connection.

   The timeout, if present, permits the caller to set up a timeout for
   all letters transmitted on the connection. If a letter is not
   successfully transmitted within the timeout period, the user is
   notified and may ignore the condition [TCP will continue trying to
   transmit] or direct the TCP to close the connection. The present
   global default is 30 seconds, and connections which are set up
   without specifying another timeout will retransmit every letter for
   at least 30 seconds before notifying the user. The retransmission
   rate may vary, and is the responsibility of the TCP and not the user.
   Most likely, it will be related to the measured time for responses to
   return from letters sent.

   Depending on the TCP implementation, either a local connection name
   will be returned to the user by the TCP, or the user will specify
   this local connection name (in which case another parameter is needed
   in the call). The local connection name can then be used as a short
   hand term for the connection defined by the <local socket, foreign
   socket> pair.

   Responses from the TCP which may occur as a result of this call are
   detailed in section 2.4.

2.3.3 SEND LETTER

   Format: SEND(local connection name, buffer address, byte count, EOL
   flag [, timeout])




Cerf, Dalal & Sunshine                                          [Page 7]

RFC 675              Specification of Internet TCP         December 1974


   This call causes the data contained in the indicated user buffer to
   be sent on the indicated connection. If the connection has not been
   opened, the SEND is considered an error. Some implementations may
   allow users to SEND first, in which case an automatic OPEN would be
   done. If the calling process is not authorized to use this
   connection, an error is returned.

   If the EOL flag is set, the data is the End Of a Letter, and the EOL
   bit will be set in the last packet created from the buffer. If the
   EOL f1ag is not set, subsequent SEND's will appear as part of the
   same letter. This extended letter facility should be used sparingly
   because some TCP's may delay processing packets until an entire
   letter is received.

   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 letter arriving for the local port] then the
   designated letter 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 the timeout is specified, then the current default timeout for
   this connection is changed to the new one. This can affect not only
   all letters sent including and after this one, but also those which
   have not yet been sent, since the timeout is kept in the TCB and not
   associated with each letter sent. Of course, a time is maintained for
   each internetwork packet formed so as to determine how long each of
   these has been on the retransmission queue.

   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. This simple method is highly subject to
   deadlocks and is not recommended. [For example both sides of the
   connection try to do SEND's before doing any RECEIVE's.] 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 concurrently. Multiple SENDs
   are served in first come, first served order, so the TCP will queue
   those it cannot service immediately.






Cerf, Dalal & Sunshine                                          [Page 8]

RFC 675              Specification of Internet TCP         December 1974


   NOTA BENE: In order for the process to distinguish among error or
   success indications for different letters, the buffer address should
   be returned along with the coded response to the SEND request. We
   will offer an example event code format in section 2.4, showing the
   information which should be returned to the calling process.

   The semantics of the INTERRUPT call are described later, but this
   call can have an effect on letters which have been given to the TCP
   but not yet sent. In particular, all such letters are flushed by the
   source TCP. Thus one of the responses to a SEND may be "flushed due
   to interrupt."

   Responses from the TCP which may occur as a result of this call are
   detailed in section 2.4.

2.3.4  RECEIVE LETTER

   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 a letter was received, or some error
   occurred, but this scheme is highly subject to deadlocks [see section
   2.3.3]. A more sophisticated implementation would permit several
   RECEIVE's to be outstanding at once, These would be filled as letters
   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.

   If insufficient buffer space is given to reassemble a complete
   letter, an indication that the buffer holds a partial letter will be
   given; the buffer will be filled with as much data as it can hold.

   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 event codes
   associated with each RECEIVE will indicate what is contained in the
   buffer.

   To distinguish among several outstanding RECEIVES, and to take care
   of the case that a letter is smaller than the buffer supplied, the
   event code is accompanied by both a buffer pointer and a byte count
   indicating the actual length of the letter received.



Cerf, Dalal & Sunshine                                          [Page 9]

RFC 675              Specification of Internet TCP         December 1974


   The semantics of the INTERRUPT system call are discussed later, but
   this call can have an effect on outstanding RECEIVES. When the TCP
   receives an INTERRUPT, it will flush all data currently queued up
   awaiting receipt by the receiving process. If no data is waiting, but
   several buffers have been made available by anticipatory RECEIVE
   commands, these buffers are returned to the process with an error
   indicating that any data that might have been placed in those buffers
   has been flushed. This enables the receiving process to synchronize
   its RECEIVES with the interrupt. That is, the process can distinguish
   between RECEIVES issued before the receipt of the INTERRUPT and these
   issued afterwards.

   Responses from the TCP which may occur as a result of this call are
   detailed in section 2.4.

2.3.5  CLOSE CONNECTION

   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. Any unfilled receive
   buffers or pending send buffers will be returned to the user with
   event codes indicating they were aborted due to the CLOSE. Users
   should wait for event codes for each SEND before closing the
   connection if they wish to be certain that all letters were
   successfully delivered.

   The user may CLOSE the connection at any time on his own initiative,
   or in response to various prompts from the TCP [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 errors.

   Responses from the TCP which may occur as a result of this call are
   detailed in section 2.4.

2.3.6  INTERRUPT

   Format: INTERRUPT(local connection name)

   A special control signal is sent to the destination indicating an
   interrupt condition. This facility can be used to simulate "break"
   signals from terminals or error or completion codes from I/O devices,
   for example. The semantics of this signal to the receiving process



Cerf, Dalal & Sunshine                                         [Page 10]

RFC 675              Specification of Internet TCP         December 1974


   are unspecified. The receiving TCP will signal the interrupt to the
   receiving process immediately upon receipt, and will also flush any
   outstanding letters waiting to be delivered. Since it is possib1e to
   tell where in the letter stream this command was invoked, it is
   possible for the receiving TCP to flush only preceding data. The
   sending TCP will flush any letters pending transmission, returning a
   special error code to indicate the flush.

   If the connection is not open or the calling process is not
   authorized to use this connection, an error is returned.

   Responses from the TCP which may occur as a result of this call are
   detailed in section 2.4.

2.3.7  STATUS

   Format: STATUS(local connection name)

   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 letters awaiting
    acknowledgment, number of letters pending receipt [including partial
    ones], default transmission timeout

    Depending on the state of the connection, 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.

    Responses from the TCP which may occur as a result of this call are
    detailed in section 2.4.

2.4  TCP TO USER MESSAGES

2.4.1  TYPE CODES

    All messages include a type code which identifies the type of user
    call to which the message applies. Types are:

    0 - General message, does not apply to a particular user call

    1 - Applies to OPEN

    2 - Applies to CLOSE




Cerf, Dalal & Sunshine                                         [Page 11]

RFC 675              Specification of Internet TCP         December 1974


    3 - Applies to INTERRUPT

    10 - Applies to SEND

    20 - Applies to RECEIVE

    30 - Applies to STATUS

2.4.2  MESSAGE FORMAT [notional]

    All messages include the following three fields:

      Type code

      Local connection name

      Event code

   For message types 0-3 [General, Open, Close, Interrupt] only these
   three fields are necessary.

   For message type 10 [Send] one additional field is necessary:

      Buffer address

   For message type 20 [Receive] three additional fields are necessary:

      Buffer address

      Byte count

      End-of-letter flag

   For message type 30 [status] additional data might include;

      Local socket, foreign socket

      Send window [measures buffer space at foreign TCP]

      Receive window [measures buffer space at local TCP]