Vendor's Support Vendors can play an important role in a support strategy, whether centralized or distributed. Part of the purchase decision-making process should be evaluating a vendor's ability to release solid, scheduled software updates, and its own help desk capabilities for client and server support. Evaluation should include not only references from customers with environments similar to yours, but also contractual commitments that include and specify financial compensation for inadequate support by the vendor. Buying The Technology Once your support issues are understood, it is finally time to implement a technology. There are two basic remote access technologies: remote control and remote node. Between these two differing approaches are any number of combinations of the two. This make for a huge variety of choices. Remote Control Background - How It Works Remote control is just that, co ntrolling one PC (or Macintosh) from another. The direction of the control is usually from the remote PC at home or on the road to the host PC back in the office, although the call can go in either direction. The host PC is left with the host software running, waiting to answer a call. When the call is established, the remote PC gets the screen or a window of the host PC and begins a remote control session. During the session the remote PC sends keyboard strokes and mouse moves that the host PC reacts to. The Remote PC receives screen changes back from the host PC. Figure 1: Remote Control Remote Access The protocol between remote and host is accomplished using propriety protocols, making one vendor's remote unable to communicate with another's host, and vice versa. The protocols that carry the keyboard, mouse and video run over popular LAN protocols like IP, IPX and NetBEUI, as well as over asynchronous connections. Each vendor maximizes throughput over these protocols using proprietary methods. Throughput is also enhanced by using compression and caching. The compression techniques often achieve outstanding file transfer results with compression ratios as high as eight to one. The caching techniques store graphics that have been loaded once on the remote in a temporary hard disk cache. They are called to the screen when needed, instead of being transferred again across the WAN link. This technique makes using remote control from within Windows, for instance, quite snappy. One of the problems with remote control is user orientation. Each time a user is connected to a host PC the network drives, servers and printers that are available from within the remote control session are not attached to the rest of the remote PC applications, stacks or operating system. For example, documents on the host PC's F: drive are not directly available to a word processor runni ng on the remote PC. Most vendors provide a drive redirection that makes either the remote PC's floppy or hard drive available as a different drive letter within the remote control session. This makes drag and drop file transfer to a local drive on the remote PC from a drive on the host PC easier, and avoids mistakenly copying a file to the host's floppy drive. Files must be transferred from the host PC to the remote PC within the remote control program, before a local program on the remote PC can open the file. A file cloning or synchronization feature in some of the better remote control products indirectly deals with this orientation problem. When the file resides on both the remote and host sides, the cloning feature transfers the changes from the host to the remote, removing the need for the user to remember which file is the latest. This is not foolproof, but solves the user's problem of working on the most recent version of a file that may have been left at the office. It still does not allow for direct access by a local productivity application to a file on the network, however. Because remote control transport is proprietary, the lack of interoperability among different vendors' communications servers is a problem. In the past, this meant that the user had to have other communications applications in order to attach to non-remote-control hosts. Two features now help this. One is integrated into the remote control client software and allows connections to communications servers that support asynchronous terminal sessions like VT-100 or ASCII. Most remote control products also support commonly-used BBS file transfer protocols like XModem and YModem. The second feature, which is more recent, is the bundling of a PPP remote node client as a separate executable with remote control software. While this is still a separate communications program, it makes remote node connections to PPP-compliant servers possible and means that users will have standardized communica tions tools. Remote control of desktops also can be accomplished over the Internet, removing the need for central-site dial-up lines. If an organization has a connection to the Internet, a remote control client can dial into a local Internet service provider using SLIP or PPP and then connect over the Internet to a remote control host back on the corporate LAN. In addition to reducing the load on the the corporate dial-up communications servers, users only have to make a local call. There is a second basic type of remote control. The desktop variety is described above and is the most common. The second works as a gateway, focusing dial-in to a single machine but facilitating remote control connections to any PC on the LAN. The gateway controls the modems and is aware of any PCs on the LAN that are running the host software, via an advertising protocol such as Int14, NASI, NCSI, or Int6B. These protocols ride on top of the LAN network protocol and register the host PC with the gateway. Most will run on IP, IPX or NetBEUI, with no difference in function. The gateways can take a couple of different forms. The first is to relegate a single desktop PC to the role of gateway, a feature of several desktop remote control packages. The desktop PC generally uses the PC's serial I/O ports and becomes dedicated to the task of being a gateway. The second form is to run the gateway as an NLM on a NetWare file server. Both can drive add-in, multiport async boards to increase the number of modems that can be attached to the gateway machine. The NLM version has this support built in and is easier to install and manage, however. A fault-tolerant hybrid of the gateway and desktop approaches is now on the market. The functionality and concept is exactly the same, with the difference being density and reliability. This hybrid generally takes the form of a chassis that houses multiple PCs. Each PC, NIC, video, mouse, serial modem port and keyboard controller is house d on a single card. The cards are placed on a single bus within the chassis. They share hot-swapable redundant power supplies. Hard and floppy drives and other add-in boards, like fax boards, are either shared or dedicated to one of these PC cards by segmenting the bus within the chassis. This hybrid fault tolerance does not stop there, however. These boxes address a significant weakness of standard desktop and gateway remote access systems. Upon disconnect of a call, the remote control host senses that the call has terminated by a change in status of one of the RS-232 pinouts on the modem interface. Upon recognizing this change, the host resets itself, readying itself for the next connection. The sensing of this disconnect change in the standard remote control packages is done within the remote control software. Occasionally a problem arises during a remote control session when the phone connection is lost and the software that was running on the host interferes with the host's ability to see the change in the RS-232 leads. This does not often happen, but when it does the host PC is no longer available for dial-in until it is rebooted. This is where the added fault tolerance of the hybrid remote control products takes over. The PC card is "hardwired," either via the bus or an actual cable and is polled by a controller within the chassis to be sure that it is still working. The RS-232 pinouts are also monitored. When a disconnect occurs, for whatever reason, or a PC card stops responding to the management controller polls, the PC card is rebooted, putting it back into service. Remote Control Management Because remote control is primarily designed for desktop access and, by extension, access to network resources attached to the desktop, centralized management is problematic. This is not to say that a remote control host cannot be managed. In fact, the gateway versions, especially the NLM and fault-tolerant hybrid approaches provide good manageme nt. It is really more of a philosophical difference. If the remote control software is going to be used for desktop access, the question is whether a non-network resource shuld be managed centrally. If the desktop is controlled by a centralized resource, the answer is yes. If it is not, and only the network resources are controlled and managed, then the answer is no. Remote Node Remote node remote access attaches the remote PC, Macintosh or Unix workstation to the LAN over a dial-up connection. Unlike remote control, where the host PC is a proxy on the LAN for the remote PC, a remote node connected PC is connected directly to the LAN. This means that any resources, such as file servers and printers, that are available to a machine connected locally to a LAN are directly available to a remote node connected PC. Figure 2: Remote Node Remote Access The remote node connection is created by directing network-layer and higher protocols over a PPP or proprietary link-layer protocol that, in turn, communicates over a physical layer that is created using a comminications port, modem and switched dial-up link. Any upper-layer protocol or stack that runs on a LAN will also run over a remote node connection if the link layer supports it. This is why so many articles claim that remote node is "just like being there", because whatever services are available to a LAN-attached machine are also available to a remote node-attached machine. The big difference is that remote node-attached machines are ten or more times slower. Files and applications that are available on the LAN will be available to a remote node machine, but the speed with which they must be accessed is so slow that caution must be employed to avoid running applications across the slow link. There are three basic remote node client transports. The Serial Line Internet Protocol (SLIP) has been around in the UNIX world for years and is still a viable way to make a remote node connection, but it only supports TCP/IP as the upper layer protocol. Proprietary transport protocols are the second way to facilitate remote node connections. They generally will carry multiple upper-layer protocols such as IP and IPX. They do not, however, allow clients to interoperate with different vendors' remote node servers. The third transport is the Point-to-Point Protocol (PPP). It is standards-based and supports multiple upper-layer protocols. Most PPP implementations support standards-based upper-layer protocols called control protocols. If a vendor's PPP client supports standard control protocols like IPCP or IPXCP, the client will interoperate with any vendor's remote node server that also supports standards-based PPP. It should be noted that a few remote node servers on the market support PPP but may not support the standardized control protocols. This prevents interoperability with third-party servers that implement standards-based PPP. With differing WinSock DLLs, protocol stacks, and PPP options, setting up a remote node client is not a trivial task. It is therefore important that whichever client is used for remote node, a rock solid install program is a must. The install should not only provide and install the stack appropriate to the LAN being attached to, it should prompt for all the necessary parameters, such as the default router and IPX network numbers. Better install programs will install all the necessary stack and dialer options from within the install program and not require the user to edit any system files. They will also read an install script that can be pre-answered by the support organization to automatically set up all LAN-specific options. Another nice install option is to create a multiple-boot system so that the client's machine can automatically load differing stacks at boot time. If controllable by a install script, the suppo rt organization can create a vanilla configuration that can be loaded to aid in problem determination. Next January 16, 1996 Print This Page E-mail this URL