Berkeley sockets

Berkeley sockets is an application programming interface for Internet domain sockets and Unix domain sockets, used for inter-process communication. It is commonly implemented as a library of linkable modules. It originated with the 4.2BSD Unix operating system, which was released in 1983.
A socket is an abstract representation for the local endpoint of a network communication path. The Berkeley sockets API represents it as a file descriptor in the Unix philosophy that provides a common interface for input and output to streams of data.
Berkeley sockets evolved with little modification from a de facto standard into a component of the POSIX specification. The term POSIX sockets is essentially synonymous with Berkeley sockets, but they are also known as BSD sockets, acknowledging the first implementation in the Berkeley Software Distribution.

History and implementations

Berkeley sockets originated with the 4.2BSD Unix operating system, released in 1983, as a programming interface. Not until 1989, however, could the University of California, Berkeley release versions of the operating system and networking library free from the licensing constraints of AT&T Corporation's proprietary Unix.
All modern operating systems implement a version of the Berkeley socket interface. It became the standard interface for applications running in the Internet. Even the Winsock implementation for MS Windows, created by unaffiliated developers, closely follows the standard.
The BSD sockets API is written in the C programming language. Most other programming languages provide similar interfaces, typically written as a wrapper library based on the C API.

BSD and POSIX sockets

As the Berkeley socket API evolved and ultimately yielded the POSIX socket API, certain functions were deprecated or removed and replaced by others. The POSIX API is also designed to be reentrant and supports IPv6.

Action	BSD	POSIX
Conversion from text address to packed address	inet_aton	inet_pton
Conversion from packed address to text address	inet_ntoa	inet_ntop
Forward lookup for host name/service	gethostbyname, gethostbyaddr, getservbyname, getservbyport	getaddrinfo
Reverse lookup for host name/service	gethostbyaddr, getservbyport	getnameinfo

Alternatives

The STREAMS-based Transport Layer Interface API offers an alternative to the socket API. Many systems that provide the TLI API also provide the Berkeley socket API.
Non-Unix systems often expose the Berkeley socket API with a translation layer to a native networking API. Plan 9 and Genode use file-system APIs with control files rather than file-descriptors.

Header files

The Berkeley socket interface is defined in several header files. The names and content of these files differ slightly between implementations. In general, they include:

File	Description
	Functions for manipulating numeric IP addresses.
	and address families and their corresponding protocol families, and. These include standard IP addresses and TCP and UDP port numbers.
	Functions for translating protocol names and host names into numeric addresses. Searches local data as well as name services.
	Core socket functions and data structures.
	and address family. Used for local communication between programs running on the same computer.

Socket API functions

The Berkeley socket API typically provides the following functions:

creates a new socket of a certain type, identified by an integer number, and allocates system resources to it.
is typically used on the server side, and associates a socket with a socket address structure, i.e. a specified local IP address and a port number.
is used on the server side, and causes a bound TCP socket to enter listening state.
is used on the client side, and assigns a free local port number to a socket. In case of a TCP socket, it causes an attempt to establish a new TCP connection.
is used on the server side. It accepts a received incoming attempt to create a new TCP connection from the remote client, and creates a new socket associated with the socket address pair of this connection.
,,, and are used for sending and receiving data. The standard functions and may also be used.
causes the system to release resources allocated to a socket. In case of TCP, the connection is terminated.
and are used to resolve host names and addresses. IPv4 only.
and are used to resolve host names and addresses. IPv4, IPv6.
is used to suspend, waiting for one or more of a provided list of sockets to be ready to read, ready to write, or that have errors.
is used to check on the state of a socket in a set of sockets. The set can be tested to see if any socket can be written to, read from or if an error occurred.
is used to retrieve the current value of a particular socket option for the specified socket.
is used to set a particular socket option for the specified socket.
socket

The function creates an endpoint for communication and returns a file descriptor for the socket. It uses three arguments:

, which specifies the protocol family of the created socket. For example:
* for network protocol IPv4
* for IPv6
* for local socket
, one of:
*
*
*
*
specifying the actual transport protocol to use. The most common are Transmission Control Protocol|, SCTP|, User Datagram Protocol|, DCCP|. These protocols are specified in file . The value may be used to select a default protocol from the selected domain and type.

The function returns if an error occurred. Otherwise, it returns an integer representing the newly assigned descriptor.

bind

associates a socket with an address. When a socket is created with, it is only given a protocol family, but not assigned an address. This association must be performed before the socket can accept connections from other hosts. The function has three arguments:

sockfd, a descriptor representing the socket
my_addr, a pointer to a structure representing the address to bind to.
addrlen, a field of type specifying the size of the structure.

returns on success and if an error occurs.

listen

After a socket has been associated with an address, listen prepares it for incoming connections. However, this is only necessary for the stream-oriented data modes, i.e., for socket types. listen requires two arguments:

sockfd, a valid socket descriptor.
backlog, an integer representing the number of pending connections that can be queued up at any one time. The operating system usually places a cap on this value.

Once a connection is accepted, it is dequeued. On success, 0 is returned. If an error occurs, -1 is returned.

accept

When an application is listening for stream-oriented connections from other hosts, it is notified of such events and must initialize the connection using function. It creates a new socket for each connection and removes the connection from the listening queue. The function has the following arguments:

sockfd, the descriptor of the listening socket that has the connection queued.
cliaddr, a pointer to a sockaddr structure to receive the client's address information.
addrlen, a pointer to a location that specifies the size of the client address structure passed to. When returns, this location contains the size of the structure.

returns the new socket descriptor for the accepted connection, or the value if an error occurs. All further communication with the remote host now occurs via this new socket.
Datagram sockets do not require processing by since the receiver may immediately respond to the request using the listening socket.

connect

establishes a direct communication link to a specific remote host identified by its address via a socket, identified by its file descriptor.
When using a connection-oriented protocol, this establishes a connection. Certain types of protocols are connectionless, most notably the User Datagram Protocol. When used with connectionless protocols, defines the remote address for sending and receiving data, allowing the use of functions such as and. In these cases, the connect function prevents reception of datagrams from other sources.
returns an integer representing the error code: represents success, while represents an error. Historically, in BSD-derived systems, the state of a socket descriptor is undefined if the call to fails, thus, portable applications should close the socket descriptor immediately and obtain a new descriptor with, in the case the call to fails.

gethostbyname and gethostbyaddr

The functions and are used to resolve host names and addresses in the domain name system or the local host's other resolver mechanisms. They return a pointer to an object of type struct hostent, which describes an Internet Protocol host. The functions use the following arguments:

name specifies the name of the host.
addr specifies a pointer to a struct in_addr containing the address of the host.
len specifies the length, in bytes, of addr.
type specifies the address family type of the host address.

The functions return in case of error, in which case the external integer may be checked to see whether this is a temporary failure or an invalid or unknown host. Otherwise a valid struct hostent* is returned.
These functions are not strictly a component of the BSD socket API, but are often used in conjunction with the API functions for looking up a host. These functions are now considered legacy interfaces for querying the domain name system. New functions that are completely protocol-agnostic have been defined. These new functions are and, and are based on a new data structure.
This pair of functions appeared at the same time as the BSD socket API proper in 4.2BSD, the same year DNS was first created. Early versions did not query DNS and only performed /etc/hosts lookup. The 4.3BSD version added DNS in a crude way. The current implementation using Name Service Switch derives Solaris and later NetBSD 1.4. Initially defined for NIS+, NSS makes DNS only one of the many options for lookup by these functions and its use can be disabled even today.