The DIGITAL TCP/IP Services for OpenVMS product supports both TCP and UDP.
TCP provides connection-oriented, reliable, sequenced data transfers between local or remote hosts. Before transmitting data, participants must establish a connection. TCP guarantees that data reaches its destination, and retransmits any data that does not get through.
UDP provides connectionless data transfers between local and remote
hosts. It allows application programs to send and receive datagrams to
applications that reside on a different host. UDP adds a checksum and
addressing information, then uses IP to deliver the datagrams. UDP
provides fast communications for applications that do not require
delivery receipts at the Transport layer.
1.6 Application Layer
The user interacts with network applications at the Application layer. Data is received as commands from the user and as data from the network application on the other end of the connection. TCP/IP applications communicate in client/server pairs at this layer.
Because of the large number of Application layer protocols supported by the DIGITAL TCP/IP for OpenVMS product, it is useful to group them in five general categories:
Sections 1.6.1 through 1.6.5 include summaries of each of
the primary Application level components included in the UCX product.
See the DIGITAL TCP/IP Services for OpenVMS User's Guide for detailed user information about remote
computing, file transfer, resource sharing, and electronic mail
components and the DIGITAL TCP/IP Services for OpenVMS Management guide for network services information
and tools.
1.6.1 Remote Computing
Remote computing applications enable networked users to run software on remote systems. UCX includes the following remote computing application components:
TELNET is a standard protocol that provides remote terminal connection or login service. TELNET enables users at one site to interact with a remote system at another site, as if the user terminals were connected directly to the remote system.
The DIGITAL TCP/IP Services for OpenVMS product implements TELNET to provide:
The remote commands, called R commands, enable users to work in accounts on remote internet hosts that are either UNIX or other OpenVMS systems. The DIGITAL TCP/IP Services for OpenVMS software supports the RLOGIN, RSH, REXEC, and RMT/RCD commands, as explained below. Users issue these commands at the system command line prompt ($).
Remote Command | Function |
---|---|
RLOGIN | Allows users of one system to log into other systems across an internet and interact as if they were directly connected. RLOGIN offers the same service as TELNET, except it also passes information about the user's environment, such as the user identification, to the remote system. |
RSH | Allows users to send a command, shell script, or command procedure to a remote host for execution. RSH does not require login to the remote host to execute commands. |
REXEC | Authenticates and executes the R commands that users issue based on password information stored in the user authentication file (UAF). |
RMT/RCD | Allows remote users to access magnetic tape and CD drives. |
For detailed information about the RLOGIN, RSH, and REXEC commands, see the DIGITAL TCP/IP Services for OpenVMS User's Guide. For information about RMT/RCD, see the DIGITAL TCP/IP Services for OpenVMS Management guide.
The Finger utility is implemented by the FINGER command, which displays information about users on the local or remote system. By default, information about each user on the host is displayed.
When you specify a user name or a list of user names with the FINGER command, the Finger utility returns the following information:
If you do not specify a host, the information listed is about users on
the local host; otherwise, the information is about users at the
specified host. You can specify a user on a remote host by using the
form user@host. If you specify @host, the standard format listing is
displayed on the remote system. The specified host must have the Finger
service enabled.
1.6.2 File Transfer
The DIGITAL TCP/IP Services for OpenVMS product includes the following file transfer components that let users transfer data files between local and remote systems:
FTP is a TCP/IP standard, high-level protocol used to transfer files bi-directionally. FTP enables users to interactively access files, list directories on a remote host, delete and rename files on the remote host, and transfer files between hosts using a wildcard character.
FTP also provides authentication control, which requires users or clients to correctly enter a login name and password to the server before requesting file transfers. The server can refuse access due to invalid login and password combinations.
FTP allows users who do not have a login name or a password to access certain files on a system using an anonymous login name. This functionality is called anonymous FTP and may include the following restrictions:
Trivial File Transfer Protocol
TFTP provides a simple, unsophisticated file transfer service. It is intended for applications that do not need complex interactions between a client and server. TFTP is small and can be encoded in read-only memory to obtain a bootstrap program. TFTP allows the bootstrapping code to use the same underlying protocols that the operating system uses once it begins execution. This makes it possible for one host to boot from a server on another physical network.
The DIGITAL TCP/IP Services for OpenVMS product supports downloading of
system images and other types of information for requesting client
hosts with TFTP.
1.6.3 Resource Sharing
Resource sharing lets users access remote system resources such as disk storage space or printers as if they were directly connected to the user's local systems. With resource sharing, users can access these resources directly after the initial connection is made. This is different from file transfer programs where files must be completely transferred from the remote system before they can be used.
The resource-sharing components of DIGITAL TCP/IP Services for OpenVMS include:
Line Printer Protocol and Line Printer Daemon Protocol
The DIGITAL TCP/IP Services for OpenVMS software provides network printing through LPR/LPD. LPD provides remote printing services for UNIX and OpenVMS client hosts. Each print queue is either local or remote. Local print queues handle inbound jobs. Remote print queues handle outbound jobs for remote printers.
The print setup utility (UCX$LPRSETUP) provides the following capabilities:
To print, users at an OpenVMS client issue the DCL-style PRINT command.
Users working on UNIX clients typically issue the lpr command.
The TELNET print symbiont (TELNETSYM) provides remote printing using the TELNET protocol. With TELNETSYM, the local OpenVMS system drives a remote printer as if it were directly connected. This is achieved by attaching a printer to a remote TCP/IP terminal server.
The TELNET print symbiont has the following functions:
Note
TELNET does not work with terminal servers that use only the local area transport (LAT) protocol.
The system that originates the print jobs handles the standard print control functions, such as header page generation, pagination, queuing, and handling of multiple forms.
TELNET printing allows the standard OpenVMS output format features not available with the LPR/LPD service. The /ON="UCX$QUEUE=name" qualifier allows you to requeue a job to another local OpenVMS queue after formatting, rather than using TELNET to send the job across the network.
For detailed information on configuring and managing TELNETSYM, see the DIGITAL TCP/IP Services for OpenVMS Management guide.
NFS is a protocol developed by Sun Microsystems, Inc., that uses IP to allow computers to access remote files as if they were local files. With NFS, when you access files and directories from a remote system, they appear to reside on your local system regardless of operating system, hardware type, or architectural differences between the local and remote systems.
This is accomplished in a client/server environment where specific implementations of NFS exist on both the client and the server machines. In its simplest form, here is how it works: When an application program executes, it calls the operating system to open a file. If the file does not reside on the local system, the request is passed to the NFS client, which knows how to contact the NFS server on the remote machine. The remote machine then performs the requested operation and replies to the client software.
In addition to NFS server and NFS client software, the DIGITAL TCP/IP Services for OpenVMS product includes PC-NFS daemon software for sharing files with personal computers. The functions of NFS server, NFS client, and PC-NFS are summarized in Table 1-2.
Communication functions such as electronic mail are vital both within an organizational internetwork and across the worldwide Internet. The electronic mail components of DIGITAL TCP/IP Services for OpenVMS are:
SMTP is the TCP/IP standard protocol for transferring electronic mail messages from one system to another. SMTP specifies how systems interact and the format of the mail messages they exchange. The UCX SMTP implementation uses the OpenVMS mail facility.
With OpenVMS Versions 6.2 and later, the OpenVMS mail facility automatically recognizes an SMTP host address, as shown in the following example:
$ MAIL MAIL> SEND To: jones@widgets.com
With SMTP mailing lists, you can send electronic mail messages to multiple users. The mailing list is a file with SMTP-style addresses of mail recipients.
An SMTP mailing list, as implemented by UCX, is considered an "alias." It operates by "forwarding" rather than by "redistributing" the mail message.
The DIGITAL TCP/IP Services for OpenVMS Post Office Protocol (POP) server and the SMTP server work together to provide a reliable mail service.
POP is a mail repository used primarily by PCs to ensure that mail is accepted even when the PC is turned off. With POP, the PC user need not be concerned with configuring the system as an SMTP server. The user logs into the client system's mail application, and the POP server forwards any new mail messages from the OpenVMS NEWMAIL folder.
The POP server is an OpenVMS implementation of the Post Office
Protocol, Version 3 (RFC 1725), and is based on the Indiana University
POP server (IUPOP3).
1.6.5 Network Services
The DIGITAL TCP/IP Services for OpenVMS product provides services that are used by system or network managers rather than directly by users. The following TCP/IP management protocols and services enable the UCX network manager to provide consistent, reliable, and efficient network services with minimal interruption:
Simple Network Management Protocol
SNMP uses the network management data standard known as the Management Information Base (MIB) to monitor gateways, networks, and hosts. The MIB specifies information about a host's network objects; information that a gateway or network management station needs in order to manage that host.
DIGITAL TCP/IP Services for OpenVMS implements an SNMP Version 1 agent and two subagents: a subset of the Host Resources MIB and MIB II. Configuring the SNMP agent on your system allows a remote SNMP network management station (also known as network management director) to obtain information about your host and set network parameters.
When a management station or other SNMP management entity first sends a request to your host, the auxiliary server invokes the SNMP agent. From then on, the agent listens for incoming requests at port 161 and responds with requested MIB data. Authentication is limited to the validation of the community name and the associated address.
The DIGITAL TCP/IP Services for OpenVMS implementation of SNMP includes an application programming interface (API) for programmers to create subagents for their specific applications. See Section 1.7 for more information about the SNMP API.
For more information on SNMP, see the DIGITAL TCP/IP Services for OpenVMS eSNMP Programming and Reference guide.
NTP is used to synchronize the time between a computer client or server and another server or reference time source such as a radio, satellite receiver, or modem. Synchronized timekeeping means that hosts with accurate system time send accurate time quotes to each other. Hosts running NTP are either time servers or clients.
Time synchronization is important in client/server computing. For example, systems that share common databases require coordinated transaction processing and time-stamping of instrumental data.
Domain Name Service (BIND Service)
The Domain Name Service (DNS) is a distributed database system that enables TCP/IP applications to convert --- or resolve --- a host name into a correct IP address. UCX implements DNS with the Berkeley Internet Name Domain (BIND) software.
BIND software, based on a client/server model, is a lookup service for the internet. BIND is divided into two components: a resolver and a name server. The resolver queries a name server and the name server responds to a resolver query:
BIND Component | Function |
---|---|
BIND resolver | Client software that requests host names, addresses, and other network information from BIND servers that maintain extensive information, rather than from the more limited local database. |
BIND server | Server software that translates host names into numeric Internet addresses and numeric Internet addresses into host names. BIND servers maintain databases of host names, addresses, mail records, text records, and other network objects. When client systems require this information, they query the servers with the BIND resolver. |
Internet hosts can simultaneously run multiple industry-standard and custom-developed services. With the portmapper, you do not need to preconfigure client applications with port numbers for each service. Instead, each server registers itself and the portmapper allocates the port. Each server process listens for connections on a designated port.
The portmapper maintains a database of the following:
Remote clients request port numbers to connect to particular applications.
The DIGITAL TCP/IP Services for OpenVMS product implements the portmapper, or inetd function, through the security and event and error logging of the auxiliary server process. The auxiliary server simplifies application writing and manages overhead by reducing simultaneous server processes on the system. In addition, the auxiliary server does the following:
Every computer attached to a TCP/IP internet needs to know its IP address before it can send or receive datagrams. Network booting with BOOTP allows a diskless machine to determine its IP address at startup so it can connect to an internet. BOOTP also allows the computer to determine the address of file servers that store and retrieve data and the address of the nearest IP gateway.
BOOTP uses UDP to transport information. A single BOOTP message
specifies items needed at startup, including the IP address, gateway
address, server address, and a field for general-purpose or
vendor-specific information, such as subnet masks or hardware
information.
1.7 Additional UCX Management and Programming Features
In addition to standard TCP/IP protocols, the DIGITAL TCP/IP Services for OpenVMS software provides the following mechanisms for managing the UCX software and developing customized applications:
The configuration procedure is a menu-driven command file that you use to enable the DIGITAL TCP/IP Services for OpenVMS software components. See the DIGITAL TCP/IP Services for OpenVMS Installation and Configuration guide for more information about the menu-driven configuration procedure.
The UCX Management Control Program is a comprehensive, easy-to-use network management tool that includes over 100 OpenVMS-style commands. These commands allow you to locally configure, monitor, and tune UCX components and to write customized applications by issuing management commands at the UCX> prompt.
To invoke the program, enter:
$ UCX
You can use the UCX Management Control Program to manage most components of UCX.
Startup and Shutdown Command Procedures
The management tools include startup and shutdown command procedures for all the components. The configuration procedure automatically runs these command procedures. The system manager can also run the procedures.
The DIGITAL TCP/IP Services for OpenVMS product provides logical names to help manage various applications, such as FTP, NFS, and SMTP. Logical names are short names assigned to a portion or an entire file specification or to a command that decreases the keystrokes necessary to complete a task. These logical names are for use by both local and remote OpenVMS users and provide backward compatibility with prior releases of DIGITAL TCP/IP Services for OpenVMS. Sometimes logical names manage UCX applications when there are no applicable UCX management commands.
For more information about how individual components use logical names, see the DIGITAL TCP/IP Services for OpenVMS Management guide.
Application Programming Interfaces
The DIGITAL TCP/IP Services for OpenVMS product supports the following application programming interfaces (APIs) for developing customized applications: