Chapter 2. 4DLT Software Fundamentals
Prev |  | Next

## Chapter 2. 4DLT Software Fundamentals

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:

- “The LAT Driver—/dev/lats”

- “The LAT Daemon—latd”

- “The User Interface Utility—slat”

- “The 4DLT Configuration Utility—lati”

- “The 4DLT Maintenance Utility—slcp”

- “How the LAT Database Works”

- “Summary of LAT Database Events”

- “The Services File and Setup Utility”

- “How Printing Works”

Figure 2-1 illustrates the components of 4DLT software.

Figure 2-1. 4DLT Software Components

## The LAT Driver—/dev/lats

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

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.

### Configuring the LAT Protocol Stack

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.

Figure 2-2. The STREAMS Stack for 4DLT

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.

### Providing Initial Database Information

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.

### Setting Up Incoming Service Connections

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.

### Multicasting Service Announcements

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 User Interface Utility—slat

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 4DLT Configuration Utility—lati

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 4DLT Maintenance Utility—slcp

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.

## How the LAT Database Works

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 LAT Database

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

#### The Default Permanent Database

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.

#### Overriding Permanent Database Values

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 LAT 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.

Figure 2-3. LAT Volatile Database Components

#### The Services Directory

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).

#### The Service Node Directory

The service node directory on an IRIS system contains this information about each LAT node whose service announcements the IRIS system is collecting:

- The service node name and description

- The address of the service node

- The availability of the node for connections

## Summary of LAT Database Events

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 Services File and Setup Utility

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

## How Printing Works

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.

Prev | Table of Contents | Next
Chapter 1. Notes to New 4DLT Administrators |  | Chapter 3. 4DLT Setup Procedures