Network library subroutines enable an application program to locate and construct network addresses while using interprocess communication facilities in a distributed environment.
Locating a service on a remote host requires many levels of mapping before client and server can communicate. A network service is assigned a name that is intended to be understandable for a user; such as "the login server on host prospero." This name and the name of the peer host must then be translated into network addresses. Finally, the address must then be used to determine a physical location and route to the service.
Network library subroutines map:
Additional network library subroutines exist to simplify the manipulation of names and addresses.
An application program must include the netdb.h file when using any of the network library subroutines.
Note: All networking services return values in standard network byte order.
The process of obtaining an Internet address from a host name is known as name resolution and is done by the gethostbyname subroutine. The process of translating an Internet address into a host name is known as reverse name resolution and is done by the gethostbyaddr subroutine.
When a process receives a symbolic host name and needs to resolve it into an address, it calls a resolver routine.
Resolver routines on hosts running Transmission Control Protocol/Internet Protocol (TCP/IP) attempt to resolve names using the following sources:
To resolve a name in a domain network, the resolver routine first queries the domain name server database, which may be local if the host is a domain name server or may be on a foreign host. Name servers translate domain names into Internet addresses. The group of names for which a name server is responsible is its zone of authority. If the resolver routine is using a remote name server, the routine uses the Domain Name Protocol (DOMAIN) to query for the mapping. To resolve a name in a flat network, the resolver routine checks for an entry in the local /etc/hosts file. When NIS is used, the /etc/hosts file on the master server is checked.
By default, resolver routines attempt to resolve names using the above resources. BIND/DNS will be tried first. If the /etc/resolv.conf file does not exist or if BIND/DNS could not find the name, NIS is queried if it is running. If NIS is not running, then the local /etc/hosts file is searched. If none of these services could find the name then the resolver routines return with HOST_NOT_FOUND. If all of the services were unavailable, then the resolver routines return with SERVICE_UNAVAILABLE.
The default order can be overwritten by creating the configuration file, /etc/netsvc.conf and specifying the desired order. Both the default and /etc/netsvc.conf can be overwritten with the environment variable NSORDER. If either the /etc/netsvc.conf file or environment variable NSORDER are defined, then at least one value must be specified along with the option.
To specify host ordering with the /etc/netsvc.conf file:
hosts = value,value,value
where value is one of the listed sources.
To specify host ordering with the NSORDER environment variable:
NSORDER=value,value,value
The order is specifed on one line with values separated by commas. White spaces are permitted between the commas and the equal sign. The values specified and their ordering depends on the network configuration. For example, if the local network is organized as a flat network, then only the /etc/hosts file is needed.
The etc/netsvc.conf file would contain the following line:
hosts=local
The NSORDER environment variable would be set as:
NSORDER=local
If the local network is a domain network using a name server for name resolution and an /etc/hosts file for backup, then both services should be specified.
The etc/netsvc.conf file would contain the following line:
hosts=bind,local
The NSORDER environment variable would be set as:
NSORDER=bind,local
Note: The values listed must be in lowercase.
The first source in the list will be tried. The algorithm will try another specified service if the:
If the /etc/resolv.conf file does not exist, then BIND/DNS is considered to be not set up or running and therefore not available. If the subroutines, getdomainname and yp_bind fail, then it is assumed that the NIS service is not set up or running and therefore not available. If the /etc/hosts file could not be opened, then a local search is impossible and therefore the file and service are unavailable.
A service listed as authoritative means that it is the expert of its successors and should have the information requested. (The other services may contain only a subset of the information in the authoritative service.) Name resolution will end after trying a service listed as authoritative even if it does not find the name. If an authoritative service is not available, then the next service specified will be queried, otherwise the resolver routine will return with HOST_NOT_FOUND.
An authoritative service is specified with the string =auth directly behind a value. The entire word authoritative can be typed in, but only the auth will be used. For example, the /etc/netsvc.conf file could contain the following line:
hosts = nis=auth,bind,local
If NIS is running, then search is ended after the NIS query regardless of whether the name was found. If NIS is not running, then the next source is queried, which is BIND.
TCP/IP name servers use caching to reduce the cost of searching for names of hosts on remote networks. Instead of searching anew for a host name each time a request is made, a name server looks at its cache to see if the host name was resolved recently. Since domain and host names do change, each item remains in the cache for a limited length of time specified by the record's time to live (TTL). In this way, authorities can specify how long they expect the name resolution to be accurate.
In a DOMAIN name server environment, the host name set using the hostname command from the command line or in the rc.net file format must be the official name of the host as returned by the name server. Generally, this name is the full domain name of the host in the form:
host.subdomain.subdomain.rootdomain
If the host name is not set up as a fully qualified domain name, and if the system is set up to use a DOMAIN name server in conjunction with the sendmail program, the sendmail configuration file (/etc/sendmail.cf) must be edited to reflect this official host name. In addition, the domain name macros in this configuration file must be set for the sendmail program to operate correctly.
Note: The domain specified in the /etc/sendmail.cf file takes precedence over the domain set by the hostname command for all sendmail functions.
For a host that is in a domain network but is not a name server, the local domain name and domain name server are specified in the /etc/resolv.conf file. In a domain name server host, the local domain and other name servers are defined in files read by the named daemon when it starts.
The following related network library subroutines map Internet host names to addresses:
The official name of the host and its public aliases are returned by the gethostbyaddr and gethostbyname subroutines, along with the address family and a null-terminated list of variable length addresses. The list of variable length addresses is required because it is possible for a host to have many addresses with the same name.
The database for these calls is provided either by the /etc/hosts file or by use of a named name server. Because of the differences in the databases and their access protocols, the information returned may differ. When using the host table version of the gethostbyname subroutine, only one address is returned, but all listed aliases are included. The name server version may return alternate addresses but does not provide any aliases other than the one given as a parameter value.
Related network library subroutines to map network names to numbers and network numbers to names are:
The getnetbyaddr, getnetbyname, and getnetent subroutines extract their information from the /etc/networks file.
Related network library subroutines to map protocol names are:
The getprotobynumber, getprotobyname, and getprotoent subroutines extract their information from the /etc/protocols file.
Related network library subroutines to map service names to port numbers are:
A service is expected to reside at a specific port and employ a particular communication protocol. The expectation is consistent within the Internet domain, but inconsistent within other network architectures. Further, a service can reside on multiple ports. If a service resides on multiple ports, the higher level library subroutines must be bypassed or extended. Services available are contained in the /etc/services file.
Related network library subroutines to convert network address byte order are:
Related network library subroutines to convert Internet addresses and dotted decimal notation are:
The hostid parameter is an integer that identifies the host machine. Host IDs fall under the category of Internet network addressing because, by convention, the 32-bit Internet address is used. The socket subroutines that manage the host ID are:
Socket subroutines to manage the internal host name are:
When a site obtains authority for part of the domain name space, it invents a string that identifies its piece of the space and uses that string as the name of the domain. To manage the domain name, applications can use the following socket subroutines: