4DLT software is composed of the LAT driver, /dev/lats; the LAT daemon, latd; a user interface utility, slat; a configuration utility, lati; and two maintenance utilities, and slcp and svc_setup. These components rely on the LAT database and on the underlying LAN Data Link layer to provide LAT functions.
This chapter explains the functions of 4DLT components and describes the structure of the LAT database. The chapter contains these sections:
Figure 2-1 illustrates the components of 4DLT software.
The LAT driver, /dev/lats, is a cloneable STREAMS device that supports AT&T's Transport Provider Interface. This driver implementation allows application developers to write Transport layer interface (TLI) programs that use LAT as a transport agent.
The LAT daemon, latd, performs functions that are fundamental to IRIS system membership in a LAT network:
Configuring the LAT protocol stack
Providing LAT database information to the IRIX kernel
Setting up incoming connections to LAT services
Multicasting service announcements to other LAT nodes
The latd daemon is normally invoked during system startup, along with other network daemons, and runs as a background process. You can also invoke latd from the command line of an active IRIX window.
The latd daemon configures the LAT protocol stack using information that it reads in the /usr/etc/lat/latconfig file (see“The Permanent LAT Database” for information on the latconfig file). The stack is implemented as configurable STREAMS modules.
Figure 2-2 illustrates the default configuration of the 4DLT protocol stack.
In the default configuration, /dev/snif is the lowest STREAMS module in the stack, immediately above the Ethernet. With the exception of /dev/snif, individual modules can be configured to customize data link and session level information processing. LAT_STREAM_1 through LAT_STREAM_ 4 modules pertain to login sessions only; these modules have no effect on printing services.
When it first starts, the LAT daemon (latd) reads a copy of /usr/etc/lat/latconfig and reports its contents to the IRIX kernel. The IRIX kernel uses latconfig as the nucleus of a working database. The kernel supplements this database with information from incoming service announcements as they arrive.
When a LAT user or LAT node requests a service such as a login session or printer, the IRIX kernel hands the request to the latd daemon. Then latd allocates a pseudo-terminal or spooler process and executes the requested service. If the requested service is a login session, latd reads and writes characters to and from the pseudo-terminals during the session.
The latd daemon multicasts service announcements to other LAT nodes to advertise the LAT services that the local IRIS system offers. When latd is started, it reads the /usr/etc/lat/latservice file for a list of the login and print services it should multicast. A default version of latservice is created when you install 4DLT software on an IRIS host (see “The Default LAT Services File”).
The slat utility is a terminal server emulation that allows an IRIS system user to connect to LAT network services and manage one or more sessions with LAT service nodes. The 4DLT User's Guide describes slat features in detail and explains how they are used.
In addition to providing the user interface to LAT services, slat also reports outgoing connection requests from local users to the IRIX kernel. If an outgoing connection to a LAT node fails, the IRIX kernel marks the node and its services ``unreachable.'' By default, unreachable nodes remain in the database for five hours, but the retention time is adjustable (“Setting Learned Service Parameters” gives details).
The LAT configuration utility, lati, is a database editor that is used to set values in the permanent 4DLT database. The permanent database is stored in a non-ASCII file called /usr/etc/lat/latconfig (see “How the LAT Database Works”).
The values that are set in /usr/etc/lat/latconfig are put into effect when latd is started. For this reason, you must stop and restart latd whenever you run lati to change latconfig.
The slcp utility is used to display information about the LAT network, manage LAT functions on the IRIS system, and modify the LAT database for day-to-day operation. Typically, a LAT administrator uses slcp to perform these tasks:
Adding and delete services
Changing service and node identification information
Setting service and CPU ratings
Setting limits on LAT sessions
Overwriting values in the /usr/etc/lat/latconfig file
Any Silicon Graphics system user can display LAT information with slcp. But slcp commands that modify LAT functions, such as those required to perform the tasks listed above, require superuser privileges—you must perform these functions as the root user.
The changes you make with slcp become effective as soon as the slcp command completes. By default, new settings are recorded in the volatile database (see “The Volatile LAT Database”) and remain in effect until you either reset them or stop latd.
 | Note: Some parameters you set with slcp can also be written to the /usr/etc/lat/latconfig file. See “Overwriting the Permanent Database” for details. |
4DLT maintains two databases: a permanent database, which is stored in the /usr/etc/lat/latconfig file, and a volatile database, which includes a memory-resident copy of the permanent database and additional LAT information that the IRIX kernel records during 4DLT operation.
The permanent database for 4DLT operation is contained in the /usr/etc/lat/latconfig file. When you first install 4DLT, the permanent database contains a default version of latconfig. The information in latconfig is read by latd, slcp, and slat.
The latconfig file stores four types of parameter that control LAT operations on the IRIS system:
The name of the IRIS node and its LAN interface
Limits on sessions and circuits supported by the IRIS system
Timers for incoming and outgoing connection events
LAT protocol stack specifications
Default operating parameters for 4DLT are already set in the as-shipped copy of /usr/etc/lat/latconfig. In most LAT environments, the default settings are suitable for optimum 4DLT operation, but in some cases, the default values will need to be changed to suit your LAT network. Chapter 5, “Reconfiguring LAT Operating Parameters,” explains how to change the latconfig file.
The lati utility is the primary means of changing the latconfig file. However, you can override some values in latconfig by issuing slcp commands. The new values take effect immediately, but they are not recorded in the permanent database unless you use a special slcp command to overwrite latconfig settings (see “Overwriting the Permanent Database”).
The volatile database consists of a copy of the permanent database and information that 4DLT software accumulates as it operates. The volatile database is stored in main memory—when latd is stopped, the volatile database is erased.
Data in the volatile database comes from four sources:
Information copied from the permanent database at latd startup
Information arriving from service announcements
Information that the LAT administrator enters using slcp
Information from failed connection attempts
Accumulated data is stored in the services directory, which contains data pertaining to LAT services, and the service node directory, which contains data pertaining to LAT nodes. Although they are referred to as directories, the services directory and service node directory are not part of the IRIX filesystem; rather, they are collections of data stored in memory on the IRIS host.
Figure 2-3 shows the components of the volatile database.
The services directory on an IRIS system contains this information about each LAT service available to the local IRIS system user:
The service name and description
The name and rating of the node offering each service
The current status of the service and its group codes
Incoming service information is referred to as learned services; learned services are dropped from the database when 4DLT is shut down. If a remote node does not refresh its service information within a specified time, the IRIX kernel marks the services from that node ``unknown.'' The unknown status is displayed in various listings to LAT users. By default, unknown nodes remain in the database for five hours, but the retention time is adjustable (“Setting Host-initiated Parameters” gives details).
Table 2-1 summarizes the events in the lifecycle of the LAT database.
Table 2-1. LAT Database Events
Event | Action Taken |
|---|---|
latd reads /usr/etc/lat/latconfig when it starts. | latd creates the volatile database by copying latconfig into IRIX kernel memory. |
latd reads incoming service announcements and other network data. | latd supplements the volatile database with the new information. |
Administrator changes database values with the slcp utility.
Administrator overwrites /usr/etc/lat/latconfig with slcp. | slcp updates the volatile database and puts new values into effect.
slcp changes the permanent database to reflect the current volatile database. |
Connection requests to remote nodes fail. | IRIX kernel updates the volatile database. |
slat user enters show services command. | slat posts a list of LAT services on the screen. |
Administrator changes database values with the lati utility. | lati changes the permanent database. New values have no effect until latd is stopped and restarted. |
latd is terminated. | Volatile database is erased from memory. |
The LAT services file, /usr/etc/lat/latservice, contains a record of each local LAT service that is to be established as part of the 4DLT startup process. A default copy of latservice is created during 4DLT installation. You add to and remove services from latservice using the /usr/etc/lat/svc_setup utility.
The purpose of latservice is to provide a permanent record of local service information, since the services directory is erased from memory during a 4DLT shutdown. Any local service that is not recorded in latservice must be recreated when 4DLT resumes operation if it is to be available to LAT users. Remote services are added to latservice as service announcements arrive.
When latd starts, it reads latservice and establishes each service that the file contains. latservice can contain two types of service:
Login services that the IRIS node offers LAT users
LAT printers that the local IRIS system user can request
LAT printer services are set up by the 4DLT administrator using the svc_setup utility (details are given in “Adding Printers to the latservice File”). These printers are known to the 4DLT user by a printer name. When the user specifies the printer name in a print command (usually lp), the printer application opens the device (an IRIX /dev file) that is associated with the remote printer as if the printer were local. However, opening the device executes 4DLT functions that send the file over the LAT network to a remote printer.
The 4DLT installation process creates 256 devices for LAT, /dev/ttyl through /dev/ttyl255. The ttyl device is reserved for internal LAT administration. Incoming session connections are assigned tty numbers that start at ttyl1 and increment with additional sessions; outgoing connection requests are assigned tty numbers that start at tty255 and decrement with additional sessions. For this reason, when you assign devices to LAT printers during the printer setup process (described in “Adding Printers to the latservice File”), you should assign the printer a tty number in the middle of the 1 to 255 range.