 |
|
|
|
Chapter 5
Dial-out Operation
For many organizations, the costs associated with providing a modem and telephone line to each user that needs access to dial-out services require that a shared modem solution be implemented. Other organizations implement modem sharing to provide increased manageability of these communications resources. WorldDesk dial-out services provide solutions for both categories of users.
WorldDesk provides a complete modem sharing facility that allows users to allocate modems attached to WorldDesk Servers. While this service is typically used in calling information service providers and bulletin board services, WorldDesk dial-out facilities may also be used to allow network-based workstations to host remote control sessions. Since both cases are handled identically from a WorldDesk perspective, this section refers to all of these services as "dial-out" services.
Dial-out Concepts
To understand how to configure the WorldDesk system for dial-out operation, it is first necessary to review a number of basic concepts.
Clusters, Servers, Ports, and Huntgroups
A cluster is a collection of WorldDesk Servers. WorldDesk Servers in a cluster may be either Commuter (dedicated, standalone) servers or Comlink (non-dedicated, Windows NT-based). Each server may have 0+120 installed ports, although Commuter servers are limited to 12 ports. These ports are collected into logical groups called huntgroups.
A huntgroup may include ports from more than one server, but its scope is limited to a single cluster. If two servers in the same cluster contain a huntgroup of the same name, the huntgroup spans both servers. By contrast, if two servers in different clusters contain a huntgroup of the same name, the huntgroups are independent.
A port may be a member of zero or more huntgroups. For example, the port COM1 may be a member of a huntgroup called "ANY", and simultaneously be a member of huntgroups "MODEM" and "V34MODEM." By default, all ports are assigned as members of a huntgroup called "ANY."
Every WorldDesk Server contains a built-in, unchangeable huntgroup whose name is the same as the server name and contains every port defined at the server. Note that it may not be possible to allocate ports in this huntgroup if dial-out use is not allowed for such ports or if dial-out security has not been permitted for a user or group of users.
Port Allocation
Users may allocate ports from a WorldDesk Server by either specifying the cluster/server/port to be allocated or by specifying a cluster/huntgroup from which a port is to be allocated. Since allocation of ports by huntgroup is automatically load balanced by WorldDesk (see "Cluster Operations for Dial-Out Support" in Chapter 2), allocation by huntgroup is the preferred mechanism. Allocation by specific port is provided primarily to allow for administrative maintenance of modems. Wildcard characters (as described below) may be used in any WorldDesk name (i.e. cluster, server, huntgroup or port).
When specific port allocation is used, the user indicates the cluster, server, port, or huntgroup to be allocated. Wildcard characters ("?" and "*") may be used in the cluster, server, huntgroup and port names in any combination. The wildcard character "?" matches exactly one character, while the wildcard character "*" matches zero or more characters. The "*" character may only appear as the last character in the name pattern; characters following a "*" in the pattern are ignored.
It is important to note that allocation of ports using the specific port allocation mechanism with wildcard characters may be used to approximate the huntgroup allocation mechanism, with one important difference. The huntgroup mechanism provides for operation of the load balancing algorithm, while specific allocation results in acquisition of the first available port that matches the specified pattern.
Port Availability for Dial-out Use
When searching for an available port for dial-out use, WorldDesk uses the same method to determine which ports are available for both specific port and huntgroup allocation methods. Only ports in state "Waiting" and "Dial-out Waiting" are considered available to dial-out users.
A port that is in state "Waiting" is ready to receive either dial-in calls or to be allocated for dial-out use. When an incoming call is detected, the port state changes and the port is no longer available for dial-out allocation. When the port is allocated for dial-out use, the outgoing DTR signal is turned off so that the attached modem will no longer answer incoming calls on that port. Note that a user that allocates the port for dial-out use may cause the DTR signal to be turned back on and may program the modem to accept calls. Such is typically the case when a shared modem is allocated by a remote control software package.
A port that is in state "Dial-out Waiting" is ready to be allocated for dial-out use. The port will not accept incoming calls.
To allow calls to be received on a port, it is necessary to check the dial-out use enabled box in the port*s configuration screen. The allowed use for a port may be dynamically changed using WorldDesk Manager without effect on any current user of the port. The change takes effect either immediately or when the port is released by its current user. By default, all ports are available for both dial-in and dial-out use.
Dial-out Security
The system administrator can configure WorldDesk to restrict access to dial-out ports. System administrators that wish to limit the ability of network users to transfer data outside of the local network may wish to implement dial-out security. Other system administrators may implement dial-out security in order to limit liability for outgoing telephone call charges.
See "Planning for Modem Pool Security" in Chapter 7 for details on implementation of dial-out security.
Using Interrupt 14 to Allocate Ports
The Interrupt 14 specification defines a programming interface by which software programs may communicate with a serial port. Originally intended as the primary mechanism by which PC-based software would program COMx ports, the Interrupt 14 interface provides a convenient mechanism by which "off-the-shelf" communications software may access WorldDesk shared modems.
The Interrupt 14 specification, although simple, has three shortcomings that reduce its effectiveness for today*s communications software:
WorldDesk*s implementation of the Interrupt 14 interface resolves the above problems, but Cubix recommends the use of other interfaces over the Interrupt 14 interface when possible.
WorldDesk Interrupt 14 Interface Design
This section provides some insight into the design of the WorldDesk Interrupt 14 redirector. The design has been influenced by an attempt to overcome the limitations described in the previous section.
The WorldDesk Interrupt 14 redirector is a DOS-based Terminate-Stay-Resident (TSR) program. It is both multiply-loadable and unloadable, as is further described below.
When the Interrupt 14 redirector is loaded, a command line argument specifies the logical COMx port to be redirected. For example, the command "INT14 COM1" specifies that the COM1 port should be redirected to a shared modem at a WorldDesk Server. In order to simultaneously allocate multiple modems, the Interrupt 14 driver may be loaded multiple times (where each time it is loaded, a different COMx port is allocated). Once allocated, the shared modem remains dedicated until the INT14 driver is unloaded or the port is manually deallocated by the user with the WDMAP.EXE program (as described below).
Performance Considerations
To overcome performance limitations as described in the previous section, the WorldDesk Interrupt 14 driver provides two special capabilities:
The fixed baud rate option allows the user to specify, at Interrupt 14 driver load time, a fixed baud rate to be used for the duration of the port allocation. Since the Interrupt 14 specification was developed before the availability of today*s high speed modems, the specification does not allow settings of typical baud rates of 38400, 57600, 115200, and beyond. Using the command line option "/BAUD=xxxx", the user instructs the Interrupt 14 driver to ignore any attempts by a communications package to set the baud rate via the programming interface. For example, the command "INT14 COM1 /BAUD=115200" may be used to allocate a shared modem, redirect COM1 to the shared modem, and send all data to the modem at 115200 bits per second.
The buffering algorithm provided by the Interrupt 14 driver is not user visible and is fully automatic. The only visible result is the higher performance and lower overhead that results from this feature. The Interrupt 14 driver monitors the communications package, detecting patterns in data transmitted and received. The driver accepts data from the terminal emulator or remote control package one character at a time, but "packages" the data into larger buffers for transmission to the WorldDesk Server via the network. Similarly, data received in larger buffers from the server are delivered a character at a time to the communications software. The algorithm used has been carefully designed to avoid "spongy" keyboard problems in remote system character echo situations.
Dynamic Port Allocation and Deallocation
As described earlier in this section, the Interrupt 14 specification does not provide a mechanism whereby the user can be presented with a list of available ports, nor can the user dynamically connect and disconnect from the server. The former capability is desirable, in that it minimizes the user knowledge required to successfully use the driver. The latter capability is desirable because it allows the shared modem to remain allocated to the user only while it is in use; this maximizes utilization of shared modem resources.
The WorldDesk Interrupt 14 driver overcomes both of these specification limitations via extensions to the Interrupt 14 service embodied in the WorldDesk WDMAP.EXE dynamic port mapping facility. The WDMAP facility is used only in conjunction with the Interrupt 14 interface; other WorldDesk redirectors provide the necessary capabilities via the corresponding programming interface specification.
The WorldDesk WDMAP.EXE mapping program allows the user to dynamically change the mapping between a loaded WorldDesk Interrupt 14 driver and an associated shared modem. By executing the WDMAP program, the user can release a currently allocated port and/or allocate a new shared modem without unloading the Interrupt 14 driver.
It is necessary to load the Interrupt 14 driver before executing WDMAP.EXE. When WDMAP is used, it is often useful to load the Interrupt 14 driver with the "/ONLYLOAD" option; the WDMAP program is then used to dynamically allocate a modem when required. Operation of the WDMAP utility is straight forward.
Note: WDMAP should be used under DOS only.
Typical Use of the WorldDesk Interrupt 14 Driver
This section provides information on the typical use of the WorldDesk Interrupt 14 driver to utilize shared WorldDesk modems. Additional command line options are available; use the command "INT14 /?" to see a complete list.
Under DOS, the Interrupt 14 driver is usually loaded from a batch file of the form:
C:\WD\INT14 COM1 /C=cluster1 /H=ANY
C:\emulator.exe
C:\WD\INT14 /U
In this example, an available port in huntgroup "ANY" is allocated from cluster "cluster1". The communications package "emulator.exe" is executed (which presumably will make use of COM1 via Interrupt 14). Finally, the Interrupt 14 driver is unloaded, releasing the shared modem.
Using NASI to Allocate Ports
The NASI specification defines a programming interface by which software programs may communicate with a shared serial port. Unlike the Interrupt 14 specification, the NASI interface was designed specifically as a shared modem interface.
The NASI interface design offers several advantages over the Interrupt 14 specification. Most importantly, the concept of dynamic allocation/deallocation of modems under communications program control is supported by NASI. Unfortunately, the late-1980s NASI design does not contain a sufficiently general naming mechanism to properly utilize the WorldDesk cluster concept. For this reason, WorldDesk provides a mapping between NASI naming and WorldDesk naming such that NASI users gain many of the advantages of the WorldDesk dial-out environment.
The NASI specification defines two classes of service: basic and advanced services. The NASI basic services provide a command interpreter through which a user manually enters commands to allocate, configure, and connect to a server port. Under NASI advanced services, the communications package performs these tasks on behalf of the user in order to simplify use of shared modems. Since all modern communications packages have taken advantage of the NASI advanced specification for a number of years, the WorldDesk NASI driver helps to reduce memory requirements by providing only the advanced services.
Translation between NASI Naming and WorldDesk Naming
NASI naming allows for specification of a server name, a general name (sometimes referred to as a service name), and a specific name for each port. Under the NASI naming model, all ports at a given server share the same server name. Each port has a unique specific name. Additionally, each port may be assigned to at most one huntgroup by specification of a single general name for the port. Each of these types of names is limited in length.
Use of the NASI interface under WorldDesk is complicated by the availability of clusters, the ability of huntgroups to span servers, the longer name lengths permitted by WorldDesk, and the ability of ports to be members of more than one huntgroup. In order to take advantage of these features, the WorldDesk NASI driver provides the following name mappings:
| WorldDesk Concept | NASI Concept |
| Cluster Name | NASI Server Name |
| Cluster/Server Name | NASI General Name |
| Cluster/Huntgroup Name | NASI General Name |
| Server/Port Name | NASI Specific Name |
The NASI server name is the top level of the NASI naming hierarchy. The NASI server is the scope in which general names and specific names are unique. The WorldDesk cluster name most closely matches this idea. As the top level of the WorldDesk naming hierarchy, all huntgroups and server names are unique within the cluster.
WorldDesk provides two mappings of WorldDesk name forms into the NASI general name. WorldDesk huntgroup names are similar to NASI general names. Since every WorldDesk Server has a built-in huntgroup that is the same as the WorldDesk Server name and contains all ports at the server, the WorldDesk Server name also maps to a NASI general name. Finally, the combination of a server name and port name within a WorldDesk cluster uniquely identifies a port; this corresponds with the NASI specific name, which uniquely specifies a port under the NASI model.
When a cluster name is concatenated with another name type by the NASI driver in order to provide the above mapping, the WorldDesk NASI driver separates the names with a "%" character to facilitate readability.
Furthermore, the NASI Service name can be mapped to the following WorldDesk Names:
Cluster%Server:Port
Cluster%Huntgroup
Server:Port
Server
HuntGroup
Some applications force the user to choose from a list, in which case the NASI Service name would map to a WorldDesk Server or Huntgroup. Other applications allow the user to manually enter the NASI Service name. When this is the case, WorldDesk NASI allows any of the above combinations.
Most WorldDesk name types allow longer names than their NASI counterparts. In order to allow use of WorldDesk huntgroups and ports by NASI users, the WorldDesk NASI driver truncates names at the limit allowed by NASI. When truncation occurs, a wildcard "*" character is substituted as the last character in the truncated name. It is important to note that this results in ambiguous names in some environments. Where this is problematic, it is recommended that the administrator assign names that fall within the more restrictive NASI limits in order to avoid such truncation.
Note: The use of underscores "_" in WorldDesk names is not recommended.
Typical Use of the WorldDesk NASI Driver
This section provides information on the typical use of the WorldDesk NASI driver to utilize shared WorldDesk modems. Additional command line options are available; use the command "NASI /?" to see a complete list.
The NASI driver is usually loaded from a batch file of the form:
C:\WD\NASI /Cluster=cluster1
C:\emulator.exe
C:\WD\NASI U
In this example, the specification of "/Cluster=cluster1" limits the scope of all NASI usage to the user*s home cluster ("cluster1"). While optional, this command line option is particularly useful at sites where multiple WorldDesk clusters exist in various locations on an interconnected network. In such cases, it is often desirable to ensure that a modem is allocated from the same cluster in which the current user is located.
In the above example, the NASI driver is unloaded following completion of the communications package "emulator.exe". This results in release of the memory used by the NASI driver. Note that under NASI, the shared modem is usually released by the communications package when the communications package completes whether or not the NASI driver is unloaded.
Using the WorldDesk COM Port Redirector for Windows 3.1x and Windows 95
Windows 3.1x and Windows for Workgroups 3.1x provide a programming interface through which Windows application programs may access local communications ports. Application programs such as TERMINAL.EXE (from the Windows Accessories group), various fax products, remote control products, and terminal emulation products use this interface to access communications ports.
In order to allow existing Windows 3.1x application programs to utilize WorldDesk shared modems, WorldDesk provides the COM port redirector for Windows 3.1x. When the WorldDesk COM port redirector is started, one or more of the logical COMx communications ports can be redirected such that they are connected to physical ports located at WorldDesk Servers. Once started, the redirection of the port is transparent to Windows application programs.
While other WorldDesk dial-out redirectors (such as INT14 and NASI) may be used in conjunction with Windows applications that support these APIs, the preferred method is via the WorldDesk COM port redirector for Windows 3.1x. The WorldDesk COM port redirector takes full advantage of WorldDesk naming services, huntgroups (and associated load balancing), and dynamic port allocation. It also provides the best performance due to block data transfers and improved buffering techniques. Perhaps the greatest benefit from this redirector is it*s support for the native Windows 3.1x communications interface.
Typical Use of the WorldDesk COM Port Redirector for Windows 3.1x and Windows 95
This section provides information on the typical use of the WorldDesk COM port redirector to utilize shared WorldDesk shared modems. More detailed online help is available in all menus via the F1 key.
To access a WorldDesk shared modem port, the WorldDesk COM port redirector must be loaded. An icon for the WorldDesk port redirector is added to the startup program group during installation. This ensures the port redirector is started whenever Windows 3.1x or Windows 95 is loaded.
When the redirector loads, its reads the last known configuration from the file WDCOM.INI (located in the Windows directory). This file specifies which COM ports are to be redirected, and to how a WorldDesk shared modem should be located. The default configuration causes COM3 to be redirected to any available WorldDesk shared modem. If the user changes these settings, the WDCOM.INI file is automatically updated.
The redirector starts as a minimized program. Like most minimized Windows programs, the program*s window can be displayed by clicking its icon with the mouse or using the Windows task list. The WorldDesk COM port redirector window provides the interface through which the user may control COM port redirection.
The COM port redirector works with up to eight logical ports. It is important to note that these ports are purely logical, and need not be associated with any "real" physical port. Each logical port is either redirected to a WorldDesk shared modem or left available for local use (via a "real" physical port on the local machine). When a port is redirected, the WorldDesk COM port redirector watches for attempts by applications to access the port. When such an application opens the port, the parameters specified in the WorldDesk COM port redirector window are used to allocate a shared modem at a WorldDesk Server. This modem remains allocated to the application until it closes the port. Thus, WorldDesk shared modems are allocated and released dynamically.
Once the WorldDesk Server has allocated a port, all commands sent to the logical port by the application are sent by the WorldDesk COM port redirector to the WorldDesk Server for handling. Similarly, responses from the WorldDesk shared modem are sent back through the redirector and delivered to the application. The application manipulates the WorldDesk shared modem port using the identical commands that it would use to manipulate a local communications port.
The selection of which logical ports are being redirected, and the WorldDesk shared modem to which these ports are dynamically connected when the port is accessed, may be changed at any time using the provided user interface. Changes made via the user interface take effect immediately, although any existing communications session is allowed to continue to completion (that is, until the port is closed).
It is important to note that communications settings for a redirected port are not set via the WorldDesk COM port redirector interface. Communications settings (such as baud rate, data bits, parity, and flow control) for the port are established by the application program (that is, terminal emulator, remote control program, or fax package) through the usual Windows programming interfaces. Consult your application program provide for details on how to control communications parameters.
This document, and all Web contents, Copyright © 1997 by Cubix Corp., Carson City, NV, USA.
