rfc675.txt

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

      Connection state [see section 4.3.6]

      Number of letters awaiting acknowledgment

      Number of letters awaiting receipt

      Retransmission timeout



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


2.4.3 EVENT CODES

   The event code specifies the particular event that the TCP wishes to
   communicate to the user.

   In addition to the event code, three flags may be useful to classify
   the event into major categories and facilitate event processing by
   the user:

      E flag: set if event is an error

      L/F flag: indicates whether event was generated by Local TCP, or
      Foreign TCP or network

      P/T flag: indicates whether the event is Permanent or Temporary
      [retry may succeed]

   Events are encoded into 8 bits with the high order bits set to
   indicate the state of the E, L/F, and P/T flags, respectively.

   Events specified so far are listed below with their codes and flag
   settings. A * means a flag does not apply or can take both values for
   this event. Additional events may be defined in the course of
   experimentation.

      0  0**  general success

      1  ELP  connection illegal for this process

      2  OF*  unspecified foreign socket has become bound

      3  ELP  connection not open

      4  ELT  no room for TCB

      5  ELT  foreign socket unspecified

      6  ELP  connection already open
         EFP  unacceptable SYN [or SYN/ACK] arrived at foreign
      TCP. Note: This is not a misprint, the local meaning is different
      from foreign.

      7  EFP  connection does not exist at foreign TCP

      8  EFT  foreign TCP inaccessible [may have subcases]

      9  ELT  retransmission timeout




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


      10 E*P  buffer flushed due to interrupt

      11 OF*  interrupt to user

      12 **P  connection closing

      13 E**  general error

      14 E*P  connection reset

   Possible events for each message type are as follows:

      Type 0[general]: 2,11,12,14

      Type 1[open]: 0,1,4,6,13

      Type 2[close]: 0,1,3,13

      Type 3[interrupt]: 0,1,3,5,7,8,9,12,13

      Type 10[send]: 0,1,3,5,7,8,9,10,11,12,13

      Type 20[receive]: 0,1,3,10,12,13

      Type 30[status]: 0,1,13

   Note that events 6(foreign), 7, 8 are generated at the foreign TCP or
   in the network[s], and these same codes are used in the error field
   of the internet packet [see section 4.2.1].

3.  HIGHER LEVEL PROTOCOLS

3.1  INTRODUCTION

   It is envisioned that the TCP will be able to support higher level
   protocols efficiently. It should be easy to interface existing
   ARPANET protocols like TELNET and FTP to the TCP.

3.2  WELL KNOWN SOCKETS

   At some point, a set of well known 24 bit port numbers must be
   picked. The type of service associated with the well known ports
   might include:

      (a)  Logger

      (b)  FTP (File transfer protocol)




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


      (c)  RJE (Remote job entry)

      (d)  Host status

      (e)  TTY Test

      (f)  HELP - descriptive, interactive system documentation

   WE RESERVE WELL KNOWN SOCKET 0 (24 bits of 0) for global messages
   destined for a particular TCP but not related to any particular
   connection. We imagine that this socket would be used for unusual TCP
   synchronization (e.g. RESET ALL) or for testing purposes (e.g.
   sending letters to TRASHCAN or ECHO). This does not conflict with the
   usage that if a socket is 0, it is unspecified, since no user can
   SEND, CLOSE, or INTERRUPT on socket 0.

3.3  RECONNECTION PROTOCOL (RCP)

   Port identifiers fall into two categories: permanent and transient.
   For example, a Logger process is generally assigned a port identifier
   that is fixed and well known. Transient processes will in general
   have ID's which are dynamically assigned.

   In the distributed processing environment of the network, two
   processes that don't have well known port identifiers may often wish
   to communicate. This can be achieved with the help of a well known
   process using a reconnection protocol. Such a protocol is briefly
   outlined using the communication facilities provided by the TCP. It
   essentially provides a mechanism by which port identifiers are
   exchanged in order to establish a connection between a pair of
   sockets.

   Such a protoco1 can be used to achieve the dynamic establishment of
   new connections in order to have multiple processes solving a problem
   cooperatively, or to provide a user process access to a server
   process via a logger, when the logger's end of the connection can not
   be invisibly passed to the server process.

   A paper on this subject by R. Schantz [SCHA74] discusses some of the
   issues associated with reconnection, and some of the ideas contained
   therein went into the design of the protocol outlined below.

   In the ARPANET, a protocol was implemented which would allow a
   process to connect to a well known socket, thus making an implicit
   request for service, and then be switched to another socket so that
   the well known socket could be freed for use by others. Since sockets





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


   in our TCP are permitted to have connections with more than one
   foreign socket, this facility may not be explicitly needed (i.e.
   connections <A,B> and <A,C> are distinguishable).

   However. the well known socket may be in one network and the actual
   service socket(s) may be in another network (or at least in another
   TCP). Thus, the invisible switching of a connection from one port to
   another within a TCP may not be sufficient as an "Initial Connection
   Protocol". We imagine that a process wishes to use socket N1.T1.Q to
   access well known socket N2.T2.P. However, the process associated
   with socket N2.T2.P will actually start up a new process somewhere
   which will use N3.T3.S as its server socket. The N(i) and T(i) may be
   distinct or the same. The user will send to N2.T2.P the relevant user
   information such as user name, password, and account. The server will
   start up the server process and send to N1.T1.Q the actual service
   socket ldentif1er: N3.T3.S. The connection (N1.TI.Q,N2.T2.P) can then
   be closed, and the user can do a RECEIVE on (N1.T1.Q,N3.T3.S). The
   serving process can SEND on (N3.T3.S,N1.T1.Q). There are many
   variations on this scheme, some involving the user process doing a
   RECEIVE on a different socket (e.g. (N1.T1.X,U.U.U)) with the server
   doing SEND on (N3.T3.S,N1.T1.X).  Without showing all the detail of
   synchronization of sequence numbers and the like, we can illustrate
   the exchange as shown below.

      USER                             SERVER

                                       1. RECEIVE(N2.T2.P,U.U.U)

      1. SEND (N1.T1.Q,N2.T2.P)==>

                                   <== 2. SEND(N2.T2.P,N1.T1.Q)

                                          With "N3.T3.S" as data

      2. RECEIVE(N1.T1.Q,N2.T2.P)

      3. CLOSE(N1.T1.Q,N2.T2.P)==>

                                   <:= 3. CLOSE(N2.T2.P,N1.T1.Q)

      4. RECEIVE(N1.T1.Q,N3.T3.S)

                                   <== 4. SEND(N3.T3.S,N1.T1.Q)

   At this point, a connection is open between N1.T1.Q and N3.T3.S. A
   variation might be to have the user do an extra RECEIVE on
   (N1.T1.X,U.U.U) and have the data "N1.T1.X" be sent in the first user
   SEND. Then, the server can start up the real serving process and do a



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


   SEND on (N3.T3.S,N1.T1.X) without having to send the "N3.T3.S" data
   to the user. Or perhaps both server and receiver exchange this data,
   to assure security of the ultimate connection (i.e. some wild process
   might try to connect to N1.T1.X if it is merely RECEIVING on foreign
   socket U.U.U.).

   We do not propose any specific reconnection protocol here, but leave
   this to further deliberation, since it is really a user level
   protocol issue.

4.  TCP IMPLEMENTATION

4.1  INTRODUCTION

   Conceptually, the TCP is made up of several processes. Some of these
   deal with USER/TCP commands, and others with packets arriving from
   the network. The TCP also has an internal measurement facility which
   can be activated remotely.

   Any particular TCP could be viewed in a number of ways. It could be
   implemented as an independent process, servicing many user processes.
   It could be viewed as a set of re-entrant library routines which
   share a common interface to the local PSN, and common buffer storage.
   It could even be viewed as a set of processes, some handling the
   user, some the input of packets from the net, and some the output of
   packets to the net.

4.2  TCP DATA STRUCTURES

4.2.1  INTERNETWORK PACKET FONMAT

   8 bits: Internet information

      2 bits: Reserved for local PSN use

      2 bits: Header format (11 in binary)

      4 bits: Protocol version number

   8 bits: Header length in octets (32 is the current value)

   16 bits: Length of text in octets

   32 bits: Packet sequence number

   32 bits: Acknowledgment number (i.e. sequence number of next octet
   expected).




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


   16 bits: Window size (in octets)

   16 bits: Control Information

      Listed from high to low order:

      SYN: Request to synchronize sending sequence numbers

      ACK: There is a valid acknowledgment in the 32 bit ACK field

      FIN: Sender will stop SENDing and RECEIVEing on this connection

      DSN: The sender has stopped using sequence numbers and wants to
      initiate a new sequence number for sending.

      EOS: This packet is the end of a segment and therefore has a
      checksum in the 16 bit checksum field. If this bit is not set, the
      16 bit checksum field is to be ignored. The bit is usually set,
      but if fragmentation at a GATEWAY occurs, the packets preceding
      the last one will not have checksums, and the last packet will
      have the checksum for the entire original fragment (segment) as it
      was calculated by the sending TCP.

      EOL: This packet contains the last fragment of a letter. The EOS
      bit will always be set in this case.

      INT: The sender wants to INTERRUPT on this connection.

      XXX: six (6) unused control bits

      OD: three (3) bits of control dispatch:

         000: Null (the control octet contents should be ignored}

         001: Event Code is present in the control octet. These were