Binding Addresses to Sockets

Edit online

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: Because 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 because 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 wanted 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 name of the system the user is logging in from is located in the /etc/hosts.equiv file on the system that the user is trying to log in to (or the system name and the user name are in the user's .rhosts file in the user's home directory).
  • The user's login process is coming from a privileged port on the machine from which the user is logging in.

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.