Specification of Internet Transmission Control Program (RFC0675)
Original Publication Date: 1974-Dec-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
V. Cerf: AUTHOR [+3]
This document describes the functions to be performed by the internetwork Transmission Control Program [TCP] and its interface to programs or users that require its services. Several basic assumptions are made about process to process communication and these are listed here without further justification. The interested reader is referred to [CEKA74, TOML74, BELS74, DALA74, SUNS74] for further discussion.
Network Working Group Vinton Cerf
Request for Comments: 675 Yogen Dalal
NIC: 2 Carl Sunshine
INWG: 72 December 1974
SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM
December 1974 Version
This document describes the functions to be performed by the
internetwork Transmission Control Program [TCP] and its interface to
programs or users that require its services. Several basic
assumptions are made about process to process communication and these
are listed here without further justification. The interested reader
is referred to [CEKA74, TOML74, BELS74, DALA74, SUNS74] for further
The authors would like to acknowledge the contributions of R.
Tomlinson (three way handshake and Initial Sequence Number
Selection), D. Belsnes, J. Burchfiel, M. Galland, R. Kahn, D. Lloyd,
W. Plummer, and J. Postel all of whose good ideas and counsel have
had a beneficial effect (we hope) on this protocol design. In the
early phases of the design work, R. Metcalfe, A. McKenzie, H.
Zimmerman, G. LeLann, and M. Elie were most helpful in explicating
the various issues to be resolved. Of course, we remain responsible
for the remaining errors and misstatements which no doubt lurk in the
nooks and crannies of the text.
Processes are viewed as the active elements of all HOST computers in
a network. Even terminals and files or other I/O media are viewed as
communicating through the use of processes. Thus, all network
communication is viewed as inter-process communication.
Since a process may need to distinguish among several communication
streams between itself and another process [or processes], we imagine
that each process may have a number of PORTs through which it
communicates with the ports of other processes.
Since port names are selected independently by each operating system,
TCP, or user, they may not be unique. To provide for unique names at
each TCP, we concatenate a NETWORK identifier, and a TCP identifier
with a port name to create a SOCKET name which will be unique
throughout all networks connected together.
A pair of sockets form a CONNECTION which can be used to carry data
in either direction [i.e. full duplex]. The connection is uniquely
identified by the
the same local socket can participate in multiple connections to
different foreign sockets [see Section 2.2].
Processes exchange finite length LETTERS as a way of communicating;
thus, letter boundaries are significant. However, the length of a
letter may be such that it must be broken into FRAGMENTS before it
can be transmitted to its destination. We assume that the fragments
will normally be reassembled into a letter before being passed to the