Museum

Home

Lab Overview

Retrotechnology Articles

⇒ Online Manual

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

inet(4F)

ip(4P)

TCP(4P)  —  SPECIAL FILES

NAME

tcp − Internet Transmission Control Protocol

SYNOPSIS

None; included automatically with inet(4F).

DESCRIPTION

TCP is a connection-oriented, end-to-end reliable protocol designed to fit into a layered hierarchy of protocols which support multi-network applications.  TCP provides for reliable inter-process communication between pairs of processes in host computers attached to distinct but interconnected computer communication networks.  Very few assumptions are made as to the reliability of the communication protocols below TCP layer.  TCP assumes it can obtain a simple, potentially unreliable datagram service from the lower level protocols.  In principle, TCP should be able to operate above a wide spectrum of communication systems ranging from hard-wired connections to packet-switched or circuit switched networks. 

TCP fits into a layered protocol architecture just above the basic Internet Protocol (IP) described in ip(4P) which provides a way for TCP to send and receive variable-length segments of information enclosed in Internet datagram “envelopes.”  The Internet datagram provides a means for addressing source and destination TCPs in different networks, deals with any fragmentation or reassembly of the TCP segments required to achieve transport and delivery through multiple netwokrs and interconnecting gateways, and has the ability to carry information on the precedence, security classification and compartmentalization of the TCP segments (although this is not currently implemented under the UNIX system.) 

An application process interfaces to TCP through the socket(2) abstraction and the related calles bind(2), listen(2), accept(2), connect(2), send(2) and recv(2). The primary purpose of TCP is to provide a reliable bidirectional virtual circuit service between pairs of processes.  In general, the TCP’s decide when to block and forward data at their own convenience. In the UNIX system implementation, it is assumed that any buffering of data is done at the user level, and the TCP’s transmit available data as soon as possible to their remote peer.  They do this and always set the PUSH bit indicating that the transferred data should be made available to the user process at the remote end as soon as practicable. 

To provide reliable data TCP must recover from data that is damaged, lost, duplicated, or delivered out of order by the underlying internet communications system.  This is achieved by assigning a sequence number to each byte of data transmitted and requiring a positive acknowledgement from the receiving TCP.  If the ACK is not received within an (adaptively determined) timeout interval, the data is retransmitted.  At the receiver, the sequence numbers are used to correctly order segments that may be received out of order and to eliminate duplicates.  Damage is handled by adding a checksum to each segment transmitted, checking it at the receiver, and discarding damaged segments.  As long as the TCP’s continue to function properly and the internet system does not become disjoint, no tranmission errors will affect the correct delivery of data, as TCP recovers from communications errors. 

TCP provides flow control over the transmitted data.  The receiving TCP is allowed to specify the amount of data which may be sent by the sender, by returning a window with every acknowledgement indicating a range of acceptable sequence numbers beyond the last segment successfully received.  The window indicates an allowed number of bytes that the sender may transmit before receiving further permission. 

TCP extends the standard 32-bit Internet host addresses with a 16-bit port number space; the combined addresses are available at the UNIX system process level in the standard sockaddr_in format described in inet(4F).

Sockets utilizing the tcp protocol are either “active” or “passive”.  Active sockets initiate connections to passive sockets.  By default TCP sockets are created active; to create a passive socket the listen(2) system call must be used after binding the socket to an address with the bind(2) system call.  Only passive sockets may use the accept(2) call to accept incoming connections.  Only active sockets may use the connect(2) call to initiate connections.

Passive sockets may “underspecify” their location to match incoming connection requests from multiple networks.  This technique, termed “wildcard addressing”, allows a single server to provide service to clients on multiple networks.  To create a socket which listens on all networks, the Internet address INADDR_ANY must be bound.  The TCP port may still be specified at this time; if the port is not specified the system will assign one.  Once a connection has been established the socket’s address is fixed by the peer entity’s location.   The address assigned the socket is the address associated with the network interface through which packets are being transmitted and received.  Normally this address corresponds to the peer entity’s network.  See inet(4F) for a complete description of addressing in the Internet family.

A TCP connection is created at the server end by doing a socket(2), a bind(2) to establish the address of the socket, a listen(2) to cause connection queueing, and then an accept(2) which returns the descriptor for the socket. A client connects to the server by doing a socket(2) and then a connect(2). Data may then be sent from server to client and back using read(2V) and write(2V).

TCP implements a very weak out-of-band mechanism, which may be invoked using the out-of-band provisions of send(2). This mechanism allows setting an urgent pointer in the data stream; it is reflected to the TCP user by making the byte after the urgent pointer available as out-of-band data and providing a SIOCATMARK ioctl which returns an integer indicating whether the stream is at the urgent mark.  The system never returns data across the urgent mark in a single read.  Thus, when a SIGURG signal is received indicating the presence of out-of-band data, and the out-of-band data indicates that the data to the mark should be flushed (as in remote terminal processing), it suffices to loop, checking whether you are at the out-of-band mark, and reading data while you are not at the mark.

SEE ALSO

inet(4F), ip(4P)

BUGS

It should be possible to send and receive TCP options. 

The system always tries to negotiates the maximum TCP segment size to be 1024 bytes.  This can result in poor performance if an intervening network performs excessive fragmentation. 

SIOCSHIWAT and SIOCGHIWAT ioctl’s to set and get the high water mark for the socket queue, and so that it can be changed from 2048 bytes to be larger or smaller, have been defined (in <sys/ioctl.h>) but not implemented. 

Sun Release 3.2  —  Last change: 26 July 1985

Typewritten Software • bear@typewritten.org • Edmonds, WA 98026