Remote Access

Remote Access

Two distinct technologies for out-of-the-office LAN users.

There are two basic ways to access your network from a hotel or from your office at home: a remote control connection or a remote node connection. The first option is conceptually simple. In effect, the dial-up telephone line becomes an extension cord for the monitor, the keyboard, and the mouse, connecting them to a computer at the host site that can log on to the network. (Remote control is possible with nonnetworked PCs, too.)

In this approach, the remote PC performs no processing operations beyond executing the remote control software itself—it simply updates the display and sends keyboard and mouse input to the host. Exchanges between remote control computers and their hosts take place at the Application level, although some remote control applications can run over networks and therefore use the network protocol stack.

Over telephone lines, direct serial links, and wireless connections, remote control programs are indifferent to whether the host is on a network. Except for the ability of remote control software to perform file transfers to and from a host, remote control is a kind of terminal emulation.

Some of the most popular remote control programs are Symantec's (Cupertino, CA) pcAnywhere, Microcom's (Norwood, MA) Carbon Copy, Traveling Software's (Bothell, WA) LapLink for Windows, Stac Electronics' (San Diego) ReachOut, and Farallon's (Alameda, CA) Timbuktu.

The principal problem with remote control solutions is their expense. A host computer with a network interface, modem, and telephone line, and a remote PC and modem, must be dedicated to every remote session. If the host machines are distributed among different offices, there are potentially serious management problems—primarily the difficulty of providing adequate security and technical support. Finding someone to physically reboot a host machine after it crashes is a potentially difficult problem. Logged-in machines spread throughout the building—with no local users—are a big security risk.

A chassis- or rack-based system of host computers on plug-in boards, such as those provided by Cubix (Carson City, NV) and J&L Information Systems (Chatsworth, CA), can enable network managers to install a high density of remote-session hosts in a central, controlled location and provide some extras such as remote rebooting capabilities and remote management. Unfortunately, the initial cost per host of these systems can be higher than the cost of most standalone PCs with comparable horsepower. (Of course, reduced support, management, and administration costs will offset the initial price difference and save money in the long run.)

In light of the obstacles to providing broad-based remote control capabilities to users, remote node software offers some significant advantages. Unlike remote control, which requires a remote user to have a dedicated modem, a PC, and a network interface, remote node sessions need only a dedicated modem and a serial port. Multiple sessions can readily share a single processor and network interface.

A remote node server is essentially a router (or sometimes a bridge) that translates frames on the serial port to a frame layout that the LAN can accommodate and then passes them along. The processor is required only to route or bridge incoming and outgoing traffic, and it would take more than 150 64Kbit/sec ISDN sessions and more than 1,000 9,600bit/sec asynchronous connections to match the throughput of a 10Mbit/sec Ethernet link—supporting a few remote nodes doesn't take a state-of-the-art microprocessor.

An approach that some software vendors have taken is to combine remote control and remote node software in a single package. Users of these products gain flexibility in matching their access method to various applications and systems.

Remote node servers can be purchased with built-in modems or with serial ports that can be connected to external modems (or to other wide-area links, such as ISDN lines).

Access Server Hardware

Remote node services can be provided through numerous hardware configurations (see Figure). Router or bridge processing can be accomplished on a processor in a dedicated box, on a communications server (including those that provide remote control services), or on a file server doing communication duty, as well as on a product sold as a router or bridge. (The file server must be able to accept add-on software that performs the routing or bridging jobs.) Multiple serial ports may be built in to a dedicated access box or mounted on boards that plug in to the communications server or file server. Standalone modems may be mounted in an external rack and plugged into serial ports. Internal or modular modems may be installed on plug-in boards, or mounted in PC Card (PCMCIA) slots.

Remote connection ports may also support high-speed ISDN connections. ISDN ports may be supplied on plug-in boards for PC-type servers, on modular boards for dedicated servers, or on standalone terminal adapter units (sometimes called "digital modems") that connect to a serial port. Some terminal adapter boxes (and terminal adapter boards that plug into a PC's bus) have integral NT1 functions, so they can connect directly to the ISDN telephone jack. Others require an external NT1 unit to provide an interface between the terminal adapter and the telephone line. To achieve the maximum possible throughput on low-cost dial-up lines, some ISDN access devices support inverse multiplexing of the two 64Kbit/sec B channels to provide as much as 128Kbits/sec throughput.

In many cases, dedicated remote access boxes are the easiest way to provide network access to remote users. Configuration problems are minimal; in fact, some of these products approach the plug-and-play level of installation ease. They may not be the least expensive solution, however, and they are not likely to offer the most flexibility for upgrading and expanding. Routers and remote bridges may be effective remote node solutions when an organization has standardized on a family of devices and wants to maintain consistency. Some devices that have been designed specifically for remote access are just about as easy to set up as a dedicated box—the primary difference is that modems or ISDN attachment equipment must be configured. PC servers that function as remote node servers will offer the biggest configuration challenges—software will have to be configured, as well as the ports that attach to the dial-up lines.

Software Options

Remote access software also comes in many flavors. Dedicated access boxes, such as those made by Shiva (Burlington, MA), Telebit (Sunnyvale, CA), and 3Com (Santa Clara, CA), run their own routing software. The U.S. Robotics (Skokie, IL) remote node server runs Cisco's (San Jose, CA) Internetwork Operating System. IBM's LAN Distance server software runs on OS/2, and AppleTalk Remote Access (ARA) can provide remote node services to Macintosh clients.

Remote Node Hardware: Self-contained remote node servers are a complete solution, with telephone and LAN interfaces built in. Remote routers and bridges often are supplied with a generic WAN port, which requires an external modem or, if ISDN lines are used, an external terminal adapter. Server-based remote nodes provide the ultimate in flexibility—even the software must be configured.

Supporting DOS and Windows remote node connections and ARA clients, Novell's NetWare Connect also provides dial-out capabilities (for DOS, Windows, and OS/2 machines) so local network clients can share modems. Windows NT includes Remote Access Server. Attachmate's (Bellevue, WA) Remote LAN Node (RLN) software supports ARA clients as well as DOS and Windows. (There is also an RLN Turnkey Server, replete with a dedicated box.)

While most traditional remote node applications use some form of proprietary interface for remote client-to-node server sessions, PPP is beginning to dominate the field. Unlike its predecessor, SLIP, PPP supports most ordinary LAN protocols—not just TCP/IP. Defined by the Internet Engineering Task Force (IETF) request for comments (RFC) process, PPP is a variant of the High-level Data Link Control (HDLC) protocol and can be thought of as a (usually slower) alternate to Ethernet or Token Ring at the Data-link layer. PPP can work with Physical layers that consist of modems and analog telephone links as well as with ISDN telephone lines. In remote node clients and servers, PPP support holds out the promise of interoperability among products from multiple hardware and software vendors.

Which One When?

Remote node access is ideal when the remote client machine has applications installed on it and the purpose of the connection is to transfer or manipulate data in relatively small doses. SQL-based database operations and desktop applications that use shared directories on a LAN for data storage lend themselves to remote node services. Because the remote pipe is a thin one—especially if modems sit between the remote client and the server—it is best to avoid 1MB- or even 100KB-sized data transfers. For example, login.exe has some 111KB. Executing this program to log in remotely can be slow if it must first be loaded over a 9,600bits/sec connection. Remote node users should keep local copies of both essential network utilities and their applications.

Traditional desktop databases, such as dBase, want to load data files into local RAM—the client itself is the database "server", and the network drive is simply a file server. Over a remote node link, access to a 1MB database will be painfully slow even if the application is installed on the remote client machine. Graphics applications also involve notoriously large files.

With large data files, and when applications are installed only on the host system, remote control provides a huge performance advantage. Because the files move across only high-speed local links and program execution is local, the thin pipe—which updates only the screen and keyboard/mouse actions—doesn't become a bottleneck. In fact, a remote control client with a pitiful 386 can take over a state-of-the-art processor at the host.

Remote e-mail is a special case. The remote clients provided by e-mail vendors such as Lotus cc:Mail (Mountain View, CA) connect via a sort of application-specific remote node connection. These connections can be assigned to a specific telephone number and the security of the connection can be managed. The remote e-mail software posts mail to the mother ship post office and downloads new messages, but will not necessarily display old messages, BBSs, and other material that would appear locally. For full-featured e-mail access to a single, complete in-box, remote control is the best choice.

With the increasing availability of ISDN connections and advances in compression technology, the demand for remote control may not grow as fast as the demand for less-costly remote node connections. Nevertheless, programs keep getting bigger, and multimedia files are generally many times the size of traditional text files, so the need for remote control won't disappear soon.

This tutorial, number 83, by Steve Steinke, was originally published in the July 1995 issue of LAN Magazine/Network Magazine.