This chapter provides brief descriptions of the VxWorks implementations of DNS and SNTP.

DNS is a distributed database that most TCP/IP applications can use to translate host names to IP addresses and back. DNS uses a client/server architecture. The client side is known as the resolver. The server side is called the name server. VxWorks provides the resolver functionality in resolvLib. For detailed information on DNS, see RFC 1034 and RFC 1035.

SNTP is a Simple Network Protocol for Time. Using an SNTP client, a target can maintain the accuracy of its internal clock based on time values reported by one or more remote sources. Using an SNTP server, the target can provide time information to other systems.

Most TCP/IP applications use Internet host names instead of IP addresses when they must refer to locations in the network. One reason for this is that host names are a friendlier human interface than IP addresses. In addition, when a host-name/IP-address pair changes, the services associated with that site typically follow the host name and not the IP address. Most applications should probably refer to network locations using host names instead of IP addresses. To make this possible, the applications need a way to translate between host names and IP addresses.

On a small isolated network, a hand-edited table is a viable solution to the look-up problem. Such a table contains entries that pair up host names with their corresponding IP addresses. If you copy this table to each host on the network, you give the applications running on those hosts the ability to translate host names to IP addresses. However, as hosts are added to the network, you must update this table and then redistribute it to all the hosts in the network. This can quickly become an overwhelming task if you must manage it manually.

As networks grow, they develop a hierarchy whose structure changes with the growth. Such restructuring can change the network addresses of almost every machine on the network. In addition, these changes are not necessarily made from a single central location. Network users at different locations can add or remove machines at will. This gives rise to a decentralized network with a dynamically changing structure. Trying to track such a structure using a static centralized table is impractical. One response to this need is the Domain Name System (DNS).

DNS is modeled after a tree architecture. The root of the tree is unnamed. Below the root comes a group of nodes. Each of these nodes represents a domain within the network. Associated with each node is a unique label, a domain name of up to 63 characters. The domain names are managed by the NIC (Network Information Center), which delegates control of the top-level domains to countries, universities, governments, and organizations.

An example of a domain name is "com", the commercial domain. Wind River Systems is a commercial organization, thus it fits under the commercial domain. The NIC has given Wind River the authority to manage the name space under "windriver.com". Wind River uses this space to name all the hosts in its network.

The VxWorks implementation of the resolver closely follows the 4.4 BSD resolver implementation. However, the VxWorks implementation differs in the way it handles the hostent structure. The 4.4 BSD resolver is a library that links with each process. It uses static structures to exchange data with the process.

This is not possible under VxWorks, which uses a single copy of the library that it shares among all the tasks in the system. All applications using the resolver library must provide their own buffers. Thus, the functions resolvGetHostByName( ) and resolvGetHostByAddr( ) require two extra parameters (for a detailed description of the interface, see the reference entries for these routines).

The VxWorks resolver library uses UDP to send requests to the configured name servers. The resolver also expects the server to handle any recursion necessary to perform the name resolution. You can configure the resolver at initialization or at run-time.¹

The resolver can also query multiple servers if you need to add redundancy to name resolution in your system. Additionally, you can configure how the resolver library responds to a failed name server query. Either the resolver looks in the static host configuration table immediately after the failed query, or the resolver ignores the static table.² The default behavior of the resolver is to query only the name server and ignore the static table.

The resolver has been fully integrated into VxWorks. Existing applications can benefit from the resolver without needing to make any code changes. This is because the code internal to hostGetByName( ) and hostGetByAddr( ) has been updated to use the resolver.³ Thus, the only thing you need do to take advantage of the resolver is to include it in your VxWorks stack.

The resolver library is not included by default in the VxWorks stack. Thus, to include the resolver in your VxWorks stack, you must set configuration parameters as follows:

1. Reconfigure VxWorks with the DNS resolver on. The relevant configuration parameter is INCLUDE_DNS_RESOLVER.

1. Establish the IP address of the Domain Name Server by changing the default value for the configuration parameter RESOLVER_DOMAIN_SERVER to the IP address of the server. The IP address of the server needs to be in dotted decimal notation (for example, 90.0.0.3).

1. Make sure that a route to the Domain Name Server exists before you try to access the resolver library. To do this, you can use mRouteAdd( ) to add the route to the routing table. However, if you have included a routing protocol such as RIP in your VxWorks stack, it will add the route for you.

1. Define the domain to which the resolver belongs by changing the default Resolver Domain (defined by the RESOLVER_DOMAIN configuration parameter).

You must change this domain name to the domain name to which your organization belongs. The resolver uses this domain name when it tries to query the domain server for the name of the host machine for its organization.

The resolver library supports a debug option, the DNS Debug Messages parameter: DNS_DEBUG. Using this parameter causes a log of the resolver queries to be printed to the console. The use of this feature is limited to a single task. If you have multiple tasks running, the output to the console will be garbled.

VxWorks supports a client and server for the Simple Network Time Protocol (SNTP). You can use the client to maintain the accuracy of your system's internal clock based on time values reported by one or more remote sources. You can use the server to provide time information to other systems.

To include the SNTP client, reconfigure your VxWorks stack. The relevant configuration parameter is INCLUDE_SNTPC. To retrieve the current time from a remote source, call sntpcTimeGet( ). This routine retrieves the time reported by a remote source and converts that value for POSIX-compliant clocks. To get time information, sntpcTimeGet( ) either sends a request and extracts the time from the reply, or it waits until a message is received from an SNTP/NTP server executing in broadcast mode. See the sntpcTimeGet( ) reference entry.

To include the SNTP server, reconfigure your VxWorks stack. The relevant configuration parameter is INCLUDE_SNTPS. If the image includes the SNTP server, it automatically calls sntpsInit( ) during system startup.

Depending on the value of the SNTP Server Mode Selection (set by the configuration parameter SNTPS_MODE), the server executes either in SNTP_PASSIVE or SNTP_ACTIVE mode. In SNTP_PASSIVE mode, the server waits for requests from clients and sends replies containing an NTP timestamp. In SNTP_ACTIVE mode, the server periodically transmits NTP timestamp information at fixed intervals.

When executing in active mode, the SNTP server determines the target IP address and broadcast interval using the configuration parameters:

• SNTPS_DSTADDR -- SNTP Server Destination Address

• SNTPS_INTERVAL -- SNTP Server Update Interval

By default, the server transmits the timestamp information to the local subnet broadcast address every 64 seconds. To change these settings after system startup, call the sntpsConfigSet( ) routine. The SNTP server operating in active mode can also respond to client requests as they arrive.

The SNTP Client/Server Port (configuration parameter SNTP_PORT) assigns the source and destination UDP port. The default port setting is 123 as specified by the RFC 1769.

Finally, the SNTP server requires access to a reliable external time source. To do this, you must provide a routine of the form:

STATUS sntpsClockHook (int request, void *pBuffer);

Until this routine is hooked into SNTP, the server cannot provide timestamp information. There are two ways to hook this routine into the SNTP server. The first is to configure VxWorks with the SNTPS Time Hook (configuration parameter SNTPS_TIME_HOOK) set to the appropriate routine name. You can also call sntpsClockSet( ). For more information, see the sntpsClockSet( ) reference entry.