Your PC can become a LAN node from virtually anywhere, but remote-access products differ in performance, compatibility, and implementation
Barry Nance
Remote-access technology has advanced to the point that, no matter where you are, your computer can become just another node on a LAN. Different implementations of remote-access schemes vary in terms of performance, ease of use, interoperability, and security. However, all of them effectively turn your modem into a network adapter.
You don't need special knowledge of remote-control techniques to use remote access. You use applications on your remote PC as you would if you were in the central office. The applications see the LAN at the remote location in the same way they'd see a LAN if you were attached to it through a workstation (although the communicati
ons link is slower). This differs from remote control, where the screen image of a slave PC on the network is mirrored on the remote computer.
Remote control tends to do well with text applications, because the central slave PC can access large files on the server without transmitting them to you. Remote access performs well if you use graphically oriented applications (e.g., Windows) and the files you access aren't huge (see the text box ``Five Ways to Connect Remotely'' on page 96DM 22). Remote access is also appropriate for client/server applications, such as database servers (e.g., Oracle, SQL Server, or perhaps DB2 for OS/2). On the other hand, transferring large files through slow modem links doesn't make sense in a remote-control or remote-access environment.
Remote access is cost-effective for organizations that have a large network and groups of people who need remote LAN access. Unlike remote control, remote access gives you transparent access to the LAN, which can help you be more pro
ductive when you're on the road.
How Remote Access Works
A remote-access product consists of two major components: a connection point in the central office and software you run on your remote PC. The central connection point might be one modem or a modem pool, and you might connect through voice-grade telephone lines, ISDN lines, or another type of telephone service (see the figure ``Remote Access'').
Usually, remote-access products use either SLIP or PPP to manage the transmission of LAN packets through the telephone connection (see ``From Here to There,'' June BYTE). To avoid unnecessary modem traffic, remote-access products also typically implement MAC-layer (media access control) bridges, with filtering, to keep the local network's broadcast traffic from clogging the telephone connection to your remote PC. Many remote-access products use a PC that is attached to the LAN as the central connection point (some vendors even supply the entire PC, preconfigured). Other products consist simp
ly of a modem that has an Ethernet or token-ring connector in addition to an RJ-11 connector.
The connection server or modem ``virtualizes'' your remote LAN session. Your application performs file I/O operations, which the network software on your PC turns into LAN messages. In turn, the remote-access driver on your remote PC converts these file I/O LAN messages into SLIP or PPP packets. The packets travel through the telephone line to the LAN.
At the central connection point, the PC or modem converts the SLIP or PPP packets into ordinary LAN messages that flow to the file server. Responses from the file server, encapsulated by SLIP or PPP, flow through the central connection point and through the modems back to your remote PC. The remote-access driver on your remote PC removes the SLIP or PPP envelope, and your redirector module receives the resulting packet. (See the figure ``Remote-Access Protocol Stack''.)
The redirector module isn't aware that the packet traveled a bit farther than m
ost LAN packets do. However, the extra time taken to transmit and receive packets through the modem means that, for remote access to function properly, you might have to increase certain time-out parameters--those in the NET.CFG file or PROTOCOL.INI file, for example.
Performance
Modems that operate at 9600 bps, 14.4 Kbps, or higher transmission rates are inexpensive and popular. Even with built-in data compression, however, modems are orders of magnitude slower than Ethernet or token-ring network adapters, which operate at 4, 10, or 16 Mbps. Makers of remote-access products try to alleviate the modem bottleneck by using packet filtering to limit the LAN packets your remote PC sees to just those packets the remote PC has requested.
The central connection point forwards selected LAN packets to your remote PC, and it might even reply to certain LAN packets on your behalf, without causing any modem traffic. For instance, servers running NetWare periodically broadcast ``Are you there?'' packe
ts to workstations. During your session, the central connection point can answer yes for you without sending data through the modem. All the central connection point needs to know is that the modem's carrier signal is still present. The central connection point doesn't have to bother your remote PC with the query.
Vendors of remote-access products are aware of the need to make your remote session appear to perform as well as it would if you were working at a locally attached workstation. A version of Intel's RemoteExpress product comes with an ISDN LAN adapter and ISDN Bridge Pack software that take advantage of ISDN's higher bandwidth. IBM's LAN Distance supports ISDN as well as X.25. Most remote-access products support 28.8-Kbps or faster modems and provide a way to exceed the speed limits that are imposed by V.32/V.42bis modems.
Ease of Use
Plainly, a modem is not a network adapter, and making it appear to be one is difficult. Modems have S-registers; LANs do not. And modems need a tel
ephone number to dial before they can connect to a LAN. On the other hand, networking software makes demands that modems are not equipped to meet. When the NETX networking module is first loaded, for example, it broadcasts a request for file servers to identify themselves. NETX won't continue unless it finds a server to connect to.
Does this mean you need to establish the remote connection at boot-up time and keep the connection active until you power off? Not necessarily. Microcom's LANexpress solves this problem by ``spoofing'' NETX into thinking a server is available, when in fact you haven't dialed into the LAN yet. Spoofing lets you load NETX when you boot up your computer, and connect to the central LAN at a later time. If, for instance, you are in the midst of running Windows applications when you decide you need to access the office LAN, you can dial up, log in, and continue your work without leaving Windows.
Another important ease-of-use issue centers around the simplicity of procedures
for setting up and configuring the central connection point. Naturally, different products take different approaches to simplifying these tasks. For example, Shiva's NetModem/E and LANRover/T for Ethernet and token-ring LANs make it easy to set up and maintain connections because they contain Ethernet or token-ring adapters. You connect the modem to the LAN at one end, connect the modem to a telephone line at the other end of the connection, and visit a workstation on the LAN to run the setup software that lets you configure such things as authorized account IDs and passwords.
Interoperability
All remote-access products support DOS and Windows; some also support remote OS/2 or Mac workstations. For protocols and networks, all vendors support NetWare, many of them support DOS LAN Requester, and some of them support the OS/2 LAN Server Requester. Support also exists for other network operating systems, such as Artisoft's LANtastic and Banyan Vines.
This diversity of protocols and network o
perating systems creates the standard dilemma. If a vendor designs its remote-access product to work closely with a particular workstation networking package (e.g., NETX), performance will be strong, but the company will have a hard time supporting a variety of platforms. On the other hand, if a vendor designs a workstation component to be completely insulated from the type of network operating system present, it will support a greater variety of networks, but its performance will suffer.
With LANexpress, Microcom chose to tie the workstation component to NetWare. IBM's LAN Distance implements its remote workstation driver software as an ANDIS module. ANDIS extends the NDIS standard to encompass such modem-oriented functions as dialing the phone and keeping track of a modem's carrier signal.
ANDIS works with modems in the same way that NDIS works with network adapters, and generally you can use an ANDIS driver in place of a regular NDIS driver for a network adapter. This degree of interoperabil
ity means that you can run any NDIS-compliant workstation network software you wish on your remote PC, and you can attach to NetWare, LAN Server, Vines, or LANtastic networks from your remote PC. If you wish, you can also run LAN management agents (e.g., SNMP) over ANDIS.
Security
Of course, you wouldn't consider using a remote-access product if remote-access technology compromised the security of your LAN. Fortunately, all remote-access products offer levels of security to prevent mischief over the telephone lines, and some go even further, allowing you to use third-party products from security database vendors.
Typical levels of security include account ID and password authorization (separate from and in addition to the network operating system's account ID and password scheme), PC address verification, preestablished telephone-number callback, password encryption, access-privilege levels, and valid log-on time intervals. Certain products support users group categories or require you to
change your password at periodic intervals.
Network adapters have burned-in node addresses that uniquely identify each adapter. Modems generally don't have unique addresses like these. However, Microcom, probably better known for its modems than for its LANexpress remote-access product, offers modems that do a good job of integrating the security features of LANexpress. Those Microcom modems intended for use with LANexpress have burned-in node addresses that appear just like the node addresses for a network adapter. A modem's identifying node addresses can be queried and verified, and you can associate names with the node addresses. You also can restrict access via remote LAN to certain node addresses and find out which modems are connected to the LAN at any given moment.
DCA's Remote LAN Node offers a similar feature. Its optional DCA remote-security adapter is a small DB-25 connector that plugs into the parallel port of a remote workstation (i.e., a dongle). When the remote workstation connec
ts to the central LAN, RLN verifies the node address burned into the DCA remote-security adapter.
Other Issues
Noisy telephone lines can be a problem for remote access, just as for any other kind of modem connection. Error-correcting modems, designing error correction into the network's transport-layer protocol, and the very nature of remote access will keep you from noticing the noise in the midst of your remote session, as you might if you were using a terminal-emulation program without an error-correcting modem. However, noisy telephone lines can degrade the performance of your remote sessions. To avoid this problem, you'll need to get a sense of the usual length of time it takes a remote workstation to access a file of a given size, so that you'll know when a particular access takes an inordinate amount of time. When performance is sluggish, the solution is redialing the connection to try to get a telephone line that has less noise.
There are alternatives to a regular telephone line,
of course. Establishing a remote office and using remote access to give that office access to your LAN might prompt you to add an ISDN or X.25 link to help performance. The number of salespeople or other business travelers in your organization will determine how many incoming telephone lines you need. However, people on business trips, connecting from hotel rooms, won't be able to take advantage of special telephone lines.
Remote access isn't always the best way to connect to a LAN. It does give the appearance of being connected to a LAN and is generally easier to use than remote control. Nonetheless, you often can process huge files through remote control quicker than you can through remote access. If you need both technologies, be creative: Use a remote-access product to connect to the LAN, and use a LAN-based remote-control product, rather than one that is modem-based, to remotely operate an application that processes huge files.
In Search of a Standard
Remote-access technology current
ly does not have a standard interface specification to which all vendors may adhere. LAN Distance's ANDIS feature is quite impressive, especially its encapsulation of the modem functions in a device-driver package that makes a modem look like a network adapter. However, effective and easy-to-use remote access can't be completely hidden within a device driver.
You can equate the opening of a network adapter to the initialization of a modem. However, the remote-access product needs to defer dialing the telephone number until you log on to the LAN. And some network-operating-system functions should behave differently for remote access.
Ideally, vendors of modems, network operating systems, and remote-access products should provide both real- and protected-mode NDIS- and ODI-compliant (Open Data-Link Interface) communications port drivers to insulate, as much as possible, the network software from the fact that the modem isn't a network adapter. The network-operating-system vendor should make its ha
ndling of broadcast packets, keep-alive packets, routing-information packets, and other network administration packets smarter and more efficient in the presence of remote-access products.
Vendors could expand their use of standard network configuration files. You might, for instance, put telephone numbers inside the NET.CFG file or the PROTOCOL.INI file. The LOGIN.EXE program for NetWare users (or LOGON.EXE, in the case of DOS LAN Requester users) could, in a remote-access environment, signal the device driver to dial a telephone number. Manufacturers could specify these and other enhancements to the hardware and software components in a remote-access environment by agreeing on an open standard for remote access.
Five Ways To Connect Remotely
1. File transfer: The simplest but least satisfying method for establishing a remote connection. If one of the computers on your LAN runs BBS software, or if you transfer a file to someone on the LAN through an E-mail service, such as
MCI Mail, your connection falls into this category.
2. Application-specific access: Downloading files from BBS software or transferring files from an E-mail service. Lotus's cc:Mail Remote is an example of application-specific access software.
3. Remote control: A connection in which you use a modem to access an in-office PC operating as a slave. Examples of remote-control products include Norton pcAnywhere from Symantec, Norton-Lambert's Close-Up, and Carbon Copy from Microcom, all of which control another PC by sending your keystrokes to a slave and echoing the remote PC's screen on your own screen.
4. Multiuser remote control: A remote-control connection that lets you handle several remote-control sessions at once. With this type of connection, the office PC must have a 386 or higher processor, lots of RAM, several modems, and multitasking software such as Novell's Access Server.
5. Remote access: A connection in which your remote PC dials up the central LAN and becomes just ano
ther workstation node.
Illustration: Remote Access
Remote access lets a modem-equipped PC connect to a central LAN. Except for the slower connection over the telephone lines, the remote client interacts with the LAN as it would with any local client.
Illustration: Remote-Access Protocol Stack
Working through a communications port, a remote-access driver can let upper layers of a protocol stack treat a modem as a network adapter.
Illustration: Microcom's LANexpress comes with easy-to-use software.
Photograph: Shiva's MetModem/E and LANRover/T products
Barry Nance is a BYTE contributing editor and a programmer. He is the author of Using OS/2 2.1 (Que, 1992-1994), Introduction to Networking (Que, 1992-1994), Network Programming in C (Que, 1990), Networking Windows for Workgroups (Wiley, 1992), and Client/Server LAN Programming (Que, 1994). You can reach him on the Internet or BIX at
barryn@bix.com
.
Connecting Remotely
