Sockets can be named with an address so that processes can connect to them. The socket layer treats an address as an opaque object. Applications supply and receive addresses as tagged, variable-length byte strings. Addresses always reside in a memory buffer (mbuf) on entry to the socket layer. A data structure called a sockaddr can be used as a template for referring to the identifying tag of each socket address.
Each address-family implementation includes subroutines for address family-specific operations. When addresses must be manipulated (for example, to compare them for equality) a pointer to the address (a sockaddr structure) is used to extract the address family tag. This tag is then used to identify the subroutine to invoke the desired operation.
Addresses passed by an application program commonly reside in mbufs only long enough for the socket layer to pass them to the supporting protocol for transfer into a fixed-sized address structure. This occurs, for example, when a protocol records an address in a protocol control block. The sockaddr structure is the common means by which the socket layer and network-support facilities exchange addresses. The size of the generic data array was chosen to be large enough to hold most addresses directly. Communications domains that support larger addresses may ignore the array size.
Transmission Control Protocol/Internet Protocol (TCP/IP) provides a set of 16-bit port numbers within each host. Because each host assigns port numbers independently, it is possible for ports on different hosts to have the same port number. TCP/IP creates the socket address as an identifier that is unique throughout all Internet networks. TCP/IP concatenates the Internet address of the local host interface with the port number to devise the Internet socket address.
With TCP/IP, sockets are not tied to a destination address. Applications sending messages can specify a different destination address for each datagram, if necessary, or they can tie the socket to a specific destination address for the duration of the connection.
Since the Internet address is always unique to a particular host on a network, the socket address for a particular socket on a particular host is unique. Additionally, since each connection is fully specified by the pair of sockets it joins, every connection between Internet hosts is also uniquely identified.
The port numbers up to 255 are reserved for official Internet services. Port numbers in the range of 256-1023 are reserved for other well-known services that are common on Internet networks. When a client process needs one of these well-known services at a particular host, the client process sends a service request to the socket address for the well-known port at the host.
If a process on the host is listening at the well-known port, the server process either services the request using the well-known port or transfers the connection to another port that is temporarily assigned for the duration of the connection to the client. Using temporarily-assigned (or secondary) ports frees the well-known port and allows the host well-known port to handle additional requests concurrently.
The port numbers for well-known ports are listed in the /etc/services file. The port numbers above 1023 are generally used by processes that need a temporary port once an initial service request has been received. These port numbers are generated randomly and used on a first-come, first-served basis.
In the AIX NDD domain, socket addresses contain the NDD name, which associates the socket with the local device (or adapter). Socket addresses also contain a protocol-dependent part.
Typically, applications use the bind subroutine to bind a socket to a particular local device and 802.2 service access point (SAP). The information used to bind to a particular NDD and packet type are specified in the NDD socket address passed into the bind subroutine. Once the socket is bound, it can be used to receive packets for the bound SAP addressed to the local host's medium access control (MAC) address (or the broadcast address) for that device. Raw packets can be transmitted using the send, sendto, and sendmsg socket subroutines.
The protocol-dependent parts of the AIX NDD socket address structure are defined as follows:
|Ethernet||The Ethernet NDD sockaddr is defined in the sys/ndd_var.h file. The sockaddr structure name is sockaddr_ndd_8022. This sockaddr allows you to bind to an Ethernet type number or an 802.2 SAP number. Once bound to a particular type or SAP, a socket can be used to receive packets of that type or SAP. Packets to be transmitted must be complete Ethernet packets that include the MAC and logical link control (LLC) headers.|
|Token Ring||The token-ring NDD sockaddr is defined in the sys/ndd_var.h file. The sockaddr structure name is sockaddr_ndd_8022. This sockaddr allows you to bind to an 802.2 SAP number. Once bound to a particular type or SAP, a socket can be used to receive packets of that type or SAP. Packets to be transmitted must be complete token ring packets that include the MAC and LLC headers.|
|FDDI||The Fiber Distributed Data Interface (FDDI) NDD sockaddr is defined in the sys/ndd_var.h file. The sockaddr structure name is sockaddr_ndd_8022. This sockaddr allows you to bind to an 802.2 SAP number. Once bound to a particular type or SAP, a socket can be used to receive packets of that type or SAP. Packets to be transmitted must be complete FDDI packets that include the MAC and LLC headers.|
|FCS||The FCS NDD sockaddr is defined in the sys/ndd_var.h file. The sockaddr structure name is sockaddr_ndd_8022. This sockaddr allows you to bind to an 802.2 SAP number. Once bound to a type or SAP, a socket can be used to receive packets of that type or SAP. Packets to be transmitted must be complete FCS packets that include the MAC and LLC headers.|
|ATM||Defined in the sockaddr_ndd_atm structure in the /sys/atmsock.h file. The sndd_atm_vc_type field specifies CONN_PVC or CONN_SVC, for Asynchronous Transfer Mode (ATM) permanent virtual circuit (PVC) and ATM switched virtual circuit (SVC), respectively. For ATM PVCs, the first four octets of the sndd_atm_addr field contain the virtual path identifier:virtual channel identifier (VPI:VCI) for a virtual circuit. For ATM SVCs, the sndd_atm_addr field contains the 20-octet ATM address, and the sndd_atm_subaddr field contains the 20-octet ATM subaddress, if applicable.|
AIX NDD protocols that support 802.2 LLC encapsulation use the sockaddr_ndd_8022 structure for defining the NDD and 802.2 SAP to be used for input filtering. Currently, the only NDD protocol that does not use this structure is ATM. The sockaddr_ndd_8022 structure contains the following fields:
|sndd_8022_len||Contains the socket address length.|
|sndd_8022_family||Contains the socket address family (for example, AF_NDD).|
|sndd_8022_nddname[NDD_MAXNAMELEN]||Contains the NDD device name for the Ethernet device (for example, ent0).|
|sndd_8022_filterlen||Contains the size of the remaining fields that define the input filter. For 802.2 encapsulated protocols, this is the size of struct ns_8022.|
|sndd_8022_ns|| Contains the filter structure and allows the application to specify the types of packets to be received by this socket. This structure contains the following fields: