Berkeley sockets
A socket is an abstract representation (handle) 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.
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.
Even the Winsock implementation for MS Windows, created by unaffiliated developers, closely follows the standard.
Most other programming languages provide similar interfaces, typically written as a wrapper library based on the C API.
They return a pointer to an object of type struct hostent, which describes an Internet Protocol host.
[6] This pair of functions appeared at the same time as the BSD socket API proper in 4.2BSD (1983),[7] the same year DNS was first created.
[8] 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.
The following lists a sampling of protocol families (preceded by the standard symbolic identifier) defined in a modern Linux or BSD implementation: A socket for communications is created with the socket() function, by specifying the desired protocol family (PF_-identifier) as an argument.
Address types were defined by additional symbolic constants, using the prefix AF instead of PF.
The AF-identifiers are intended for all data structures that specifically deal with the address type and not the protocol family.
However, this concept of separation of protocol and address type has not found implementation support and the AF-constants were defined by the corresponding protocol identifier, leaving the distinction between AF and PF constants as a technical argument of no practical consequence.
[11] The POSIX.1—2008 specification doesn't specify any PF-constants, but only AF-constants[12] Raw sockets provide a simple interface that bypasses the processing by the host's TCP/IP stack.
The application must check the return value to determine how many bytes have been sent or received and it must resend any data not already processed.
If not written correctly, programs using non-blocking sockets are particularly susceptible to race conditions due to variances in network link speed.
[citation needed] A socket is typically set to blocking or non-blocking mode using the functions fcntl and ioctl.
The programs contains an infinite loop that receives UDP datagrams with function recvfrom().
