Internet socket:
An Internet socket (or commonly, a network socket or socket), is an end-point of a bidirectional process-to-process communication flow across an IP based network, such as the Internet. Each socket is mapped to an application process or thread. A socket is an interface between an application process or thread and the TCP/IP protocol stack provided by the operating system.
An Internet socket is identified by the operating system as a unique combination of the following:
- Protocol (TCP, UDP or raw IP)
- Local IP address
- Local port number
- Remote IP address (Only for established TCP sockets)
- Remote port number (Only for established TCP sockets)
The operating system forwards incoming IP data packets to the corresponding application process by extracting the above socket address information from the IP, UDP and TCP headers.
A somewhat simplified definition occurring in the literature follows: "The combination of an IP address and a port number is referred to as a socket."[1] See also RFC 147 for the original definition of socket as it was related to the ARPA network in 1971.
Communicating local and remote sockets are called socket pairs.
On Unix-like operating systems the netstat -an command-line tool lists all currently established sockets. On some system, netstat -b lists sockets created by application programs.
[edit] Socket types
There are three Internet socket types:
- Datagram sockets, also known as connectionless sockets, which use UDP
- Stream sockets, also known as connection-oriented sockets, which use TCP or SCTP.
- Raw sockets (or Raw IP sockets), typically available in routers and other network equipment. Here the transport layer is bypassed, and the packet headers are not stripped off, but are accessible to the application. Application examples are ICMP, IGMP and OSPF. [2]
(There are also non-Internet sockets, implemented over other transport protocols, such as SNA [1]. See also Unix domain sockets (UDS), for internal inter-process communication.)
[edit] Socket states and the client-server model
A TCP socket may be in listening state. An example is a server process waiting for remote clients to take initiative on communication. For a listening TCP socket, the remote address presented by netstat may be denoted 0.0.0.0 and the remote port number 0.
A TCP socket may also be in the established state, meaning that a socket-to-socket virtual connection or virtual circuit (VC), also known as a TCP session, is established with a remote client, providing a duplex byte stream. Other possible TCP socket states presented by the netstat command are Syn-sent, Syn-Recv, Fin-wait1, Fin-wait2, Time-wait, Close-wait and Closed[3].
A server may create several concurrently established TCP sockets with the same local port number and local IP address, each mapped to its own server-child process, serving its own client process. They are treated as different sockets by the operating system, since the remote client address or port numbers are different.
A UDP socket may not be in established state, since UDP is connectionless. Netstat does not show the state of a UDP socket. A UDP server does not create new child processes for every concurrently served client, but the same process is processing incoming data packets from all remote clients iteratively through the same local UDP socket. This implies that UDP sockets are not identified by the remote address, but only by the local address.
[edit] Implementation issues
Sockets are usually implemented by an API library such as Berkeley sockets, first introduced in 1983. Most implementations are based on Berkeley sockets, for example Winsock introduced 1991. Other socket API implementations exist, such as the STREAMS-based Transport Layer Interface (TLI).
Development of application programs that utilize this API is called socket programming or network programming.
These are examples of functions or methods typically provided by the API library:
socket() creates a new socket of a certain socket type, identified by an integer number, and allocates system resources to it.bind() is typically used on the server side, and associates a socket with a socket address structure, i.e. a specified local port number and IP address.listen() is used on the server side, and causes a bound TCP socket to enter listening state.connect() 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.accept() 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.send() and recv(), or write() and read(), or recvfrom() and sendto(), are used for sending and receiving data to/from a remote socket.close() causes the system to release resources allocated to a socket. In case of TCP, the connection is terminated.
[edit] Socket support in network equipment
Network equipment such as routers and switches traditionally do not deal with the socket identifiers of the routed or switched data. However, stateful network firewalls and Network Address Translation proxy servers automatically keep track of all active socket pairs, UDP as well as TCP, based on certain time-out settings. Also in fair queuing, layer 3 switching and Quality of Service support in routers, packet flows may be identified by extracting information about the socket pairs.
Raw sockets are typically available in network equipment, and used for routing protocols such as IGMP and OSPF, and in ICMP.
[edit] Options for Sockets
After creating a socket, it is possible to set options on it. Some of the more common options are:
TCP_NODELAY disables the Nagle algorithm.SO_KEEPALIVE enables periodic 'liveness' pings, if supported by the OS.
[edit] See also
[edit] External links
|
