The socket subroutine creates a socket without a name. An unnamed socket is one without any association to local or destination addresses. Until a name is bound to a socket, processes have no way to reference it and consequently, no message can be received on it.
Communicating processes are bound by an association. The bind subroutine allows a process to specify half of an association: local address, local port, or local path name. The connect and accept subroutines are used to complete a socket's association. Each domain association can have a different composite of addresses. The following domain associations are:
An application program may not care about the local address it uses and may allow the protocol software to select one. This is not true for server processes. Server processes that operate at a well-known port need to be able to specify that port to the system.
In most domains, associations must be unique. Internet domain associations must never include duplicate protocol, local address, local port, foreign address, or foreign port tuples.
UNIX domain sockets need not always be bound to a name, but when bound can never include duplicate protocol, local path name, or foreign path name tuples. The path names cannot refer to files already on the system.
The bind subroutine accepts the Socket, Name, and NameLength parameters. The Socket parameter is the integer descriptor of the socket to be bound. The Name parameter specifies the local address, and the NameLength parameter indicates the length of address in bytes. The local address is defined by a data structure termed sockaddr.
In the Internet domain, a process does not have to bind an address and port number to a socket, because the connect and send subroutines automatically bind an appropriate address if they are used with an unbound socket.
In the NDD domain, a process must bind a local NDD name to a socket.
The bound name is a variable-length byte string that is interpreted by the supporting protocols. Its interpretation can vary from communication domain to communication domain (this is one of the properties of the domain). In the Internet domain, a name contains an Internet address, a length, and a port number. In the UNIX domain, a name contains a path name, a length, and an address family, which is always AF_UNIX.
Binding addresses to sockets in the Internet domain demands a number of considerations. Port numbers are allocated out of separate spaces, one for each system and one for each domain on that system.
Note: Since the association is created in two steps, the association uniqueness requirement indicated previously could be violated unless care is taken. Further, user programs do not always know proper values to use for the local address and local port since a host can reside on multiple networks, and the set of allocated port numbers is not directly accessible to a user.
Wildcard addressing is provided to aid local address binding in the Internet domain. When an address is specified as INADDR_ANY (a constant defined in the netinet/in.h file), the system interprets the address as any valid address.
Sockets with wildcard local addresses may receive messages directed to the specified port number and sent to any of the possible addresses assigned to a host. If a server process wished to connect only hosts on a given network, it would bind the address of the hosts on the appropriate network.
A local port can be specified or left unspecified (denoted by 0), in which case the system selects an appropriate port number for it.
The restriction on allocating ports was done to allow processes executing in a secure environment to perform authentication based on the originating address and port number. For example, the rlogin(1) command allows users to log in across a network without being asked for a password, if two conditions hold:
The port number and network address of the machine from which the user is logging in can be determined either by the From parameter result of the accept subroutine, or from the getpeername subroutine.
In certain cases, the algorithm used by the system in selecting port numbers is unsuitable for an application program. This is because associations are created in a two-step process. For example, the Internet File Transfer Protocol (FTP) specifies that data connections must always originate from the same local port. However, duplicate associations are avoided by connecting to different foreign ports. In this situation, the system disallows binding the same local address and port number to a socket if a previous data connection socket still exists. To override the default port selection algorithm, a setsockopt subroutine must be performed before address binding.
The socket subroutine creates a socket without any association to local or destination addresses. For the Internet protocols, this means no local protocol port number has been assigned. In many cases, application programs do not care about the local address they use and are willing to allow the protocol software to choose one for them. However, server processes that operate at a well-known port must be able to specify that port to the system. Once a socket has been created, a server uses the bind subroutine to establish a local address for it.
Not all possible bindings are valid. For example, the caller might request a local protocol port that is already in use by another program, or it might request an invalid local Internet address. In such cases, the bind subroutine is unsuccessful and returns an error message.
New sockets sometimes inherit the set of open sockets that created them. The sockets program interface includes subroutines that allow an application to obtain the address of the destination to which a socket connects and the local address of a socket. The socket subroutines that allow a program to retrieve socket addresses are:
For additional information that you may need before binding or obtaining socket addresses, read the following concepts: