Mac Developer Library Developer
Search

 

This manual page is for Mac OS X version 10.9

If you are running a different version of Mac OS X, view the documentation locally:

  • In Terminal, using the man(1) command

Reading manual pages

Manual pages are intended as a quick reference for people who already understand a technology.

  • To learn how the manual is organized or to learn about command syntax, read the manual page for manpages(5).

  • For more information about this technology, look for other documentation in the Apple Developer Library.

  • For general information about writing shell scripts, read Shell Scripting Primer.




TCP(4)                   BSD Kernel Interfaces Manual                   TCP(4)

NAME
     tcp -- Internet Transmission Control Protocol

SYNOPSIS
     #include <sys/types.h>
     #include <sys/socket.h>
     #include <netinet/in.h>

     int
     socket(AF_INET, SOCK_STREAM, _);

DESCRIPTION
     The TCP protocol provides reliable, flow-controlled, two-way transmission of data.  It is a byte-stream
     protocol used to support the SOCK_STREAM abstraction.  TCP uses the standard Internet address format
     and, in addition, provides a per-host collection of ``port addresses''.  Thus, each address is composed
     of an Internet address specifying the host and network, with a specific TCP port on the host identify-ing identifying
     ing the peer entity.

     Sockets utilizing the TCP protocol are either ``active'' or ``passive''.  Active sockets initiate con-nections connections
     nections 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 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 speci-fied, specified,
     fied, 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 to 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.

     TCP supports a number of socket options which can be set with setsockopt(2) and tested with
     getsockopt(2):

     TCP_NODELAY            Under most circumstances, TCP sends data when it is presented; when outstanding
                            data has not yet been acknowledged, it gathers small amounts of output to be
                            sent in a single packet once an acknowledgement is received.  For a small number
                            of clients, such as window systems that send a stream of mouse events which
                            receive no replies, this packetization may cause significant delays.  The
                            boolean option TCP_NODELAY defeats this algorithm.

     TCP_MAXSEG             By default, a sender- and receiver-TCP will negotiate among themselves to deter-mine determine
                            mine the maximum segment size to be used for each connection.  The TCP_MAXSEG
                            option allows the user to determine the result of this negotiation, and to
                            reduce it if desired.

     TCP_NOOPT              TCP usually sends a number of options in each packet, corresponding to various
                            TCP extensions which are provided in this implementation.  The boolean option
                            TCP_NOOPT is provided to disable TCP option use on a per-connection basis.

     TCP_NOPUSH             By convention, the sender-TCP will set the ``push'' bit, and begin transmission
                            immediately (if permitted) at the end of every user call to write(2) or
                            writev(2).  When this option is set to a non-zero value, TCP will delay sending
                            any data at all until either the socket is closed, or the internal send buffer
                            is filled.

     TCP_KEEPALIVE          The TCP_KEEPALIVE options enable to specify the amount of time, in seconds, that
                            the connection must be idle before keepalive probes (if enabled) are sent.  The
                            default value is specified by the MIB variable net.inet.tcp.keepidle.

     TCP_CONNECTIONTIMEOUT  The TCP_CONNECTIONTIMEOUT option allows to specify the timeout, in seconds, for
                            new, non established TCP connections. This option can be useful for both active
                            and passive TCP connections. The default value is specified by the MIB variable
                            net.inet.tcp.keepinit.

     The option level for the setsockopt(2) call is the protocol number for TCP, available from
     getprotobyname(3), or IPPROTO_TCP.  All options are declared in <netinet/tcp.h>.

     Options at the IP transport level may be used with TCP; see ip(4).  Incoming connection requests that
     are source-routed are noted, and the reverse source route is used in responding.

   Non-blocking connect
     When a TCP socket is set non-blocking, and the connection cannot be established immediately, connect(2)
     returns with the error EINPROGRESS, and the connection is established asynchronously.

     When the asynchronous connection completes successfully, select(2) or poll(2) or kqueue(2) will indi-cate indicate
     cate the file descriptor is ready for writing.  If the connection encounters an error, the file
     descriptor is marked ready for both reading and writing, and the pending error can be retrieved via the
     socket option SO_ERROR.

     Note that even if the socket is non-blocking, it is possible for the connection to be established imme-diately. immediately.
     diately. In that case connect(2) does not return with EINPROGRESS.

DIAGNOSTICS
     A socket operation may fail with one of the following errors returned:

     [EISCONN]          when trying to establish a connection on a socket which already has one;

     [ENOBUFS]          when the system runs out of memory for an internal data structure;

     [ETIMEDOUT]        when a connection was dropped due to excessive retransmissions;

     [ECONNRESET]       when the remote peer forces the connection to be closed;

     [ECONNREFUSED]     when the remote peer actively refuses connection establishment (usually because no
                        process is listening to the port);

     [EADDRINUSE]       when an attempt is made to create a socket with a port which has already been allo-cated; allocated;
                        cated;

     [EADDRNOTAVAIL]    when an attempt is made to create a socket with a network address for which no net-work network
                        work interface exists;

     [EAFNOSUPPORT]     when an attempt is made to bind or connect a socket to a multicast address;

     [EINPROGRESS]      returned by connect(2) when the socket is set nonblocking, and the connection cannot
                        be immediately established;

     [EALREADY]         returned by connect(2) when connection request is already in progress for the speci-fied specified
                        fied socket.

SEE ALSO
     connect(2), getsockopt(2), kqueue(2), poll(2), select(2), socket(2), sysctl(3), inet(4), inet6(4),
     ip(4), ip6(4), netintro(4), setkey(8)

HISTORY
     The TCP protocol appeared in 4.2BSD.

     The socket option TCP_CONNECTIONTIMEOUT first appeared in Mac OS X 10.6.

4.2 Berkeley Distribution      February 28, 2007     4.2 Berkeley Distribution

Reporting Problems

The way to report a problem with this manual page depends on the type of problem:

Content errors
Report errors in the content of this documentation with the feedback links below.
Bug reports
Report bugs in the functionality of the described tool or API through Bug Reporter.
Formatting problems
Report formatting mistakes in the online version of these pages with the feedback links below.

Feedback