Combining Remote Node and Remote Control Remote control vendors have added remote node clients to their client installs, and remote node vendors have added remote control clients to their client's packages, as a separate executable. This has two advantages. First, using applications that are too slow to run over the slow dial-up links of remote node, a user has a client that can enable that application remotely, without IS having to rewrite the application. The downside is that the remote user needs to know which applications go with which connection type, and central support needs either to make the remote control host software available or to create a pool of shared remote control hosts in addition to the remote node servers. The second advantage is that combining remote control and remote node allows Help Desk personnel to take a look at the configuration of a remote machine that is having a problem. While it is unlikley that a user will have the ability or phone lines to support both remote node and remote control sessions simultaneously, trained help desk personnel will be able to save plenty of support time. Remote node clients range in their feature sets from fairly bare-bones dialers to full-fledged automation tools. The addition of scripting languages and icons to kick off automated scripts for dialing, drive mappings and application execution can help reduce users' errors when connecting. In the better clients, these can be predefined by the support organization. One of the strongest features of remote node is the manageability and scalability of the central-site servers. At the low end, most will support 8 to 12 ports, some including modems. Larger systems will support as many as seventy-two ports in a single chassis. All are SNMP manageable and come with management software. Management software differs among vendors. All will administer the ports on both the LAN and modem sides of the dial-in server. The all also will provide some sort of local user authentication. The more advanced management software also manages modems and the interface to one or more third-party user registries like Novell NDS, or TACAS. Some also have the ability to manage multiple remote node servers. Alternatives Besides the alternatives of mixed remote control and remote node clients there are a couple of other interesting remote access options available. Multi-user Application Server Figure 3: Multiuser Application Server A hybrid remote-control-like solution, a multi-user application server may offer one of the best hopes for manageable, scaleable, fast remote access. While not strictly a remote access device, the multi-user application server run applications and only transfers the keystrokes, mouse movements and video updates. It sounds like remote con trol, but the difference is that it is designed to handle several users per host, is more efficient, and consequently is faster than remote control Like remote control, the multi-user application server requires no redesign of current applications to run them over the slow wide-area link. The applications server itself sits on the LAN and runs on a multiprocessing, multi-threading operating system like OS/2 or Windows NT. Users log on to the server and start one or more native OS or DOS sessions using a proprietary client and transport. The user can be on the LAN or, because the client is small and uses very little bandwidth, on the other side of a switched wide-area link. Unlike remote control, the client video I/O is faster. Video changes are intercepted by the application server at the operating system's Graphical Device Interface. This is the same near-hardware level at which the operating system is handling video changes. This is in contrast to remote control packages that receive their changes at the user-interface level, which is slower because it has to go through another layer of processing before the remote control program can get to it. The application server transfers the unformatted video to the remote client, where it is then formatted for the UI. What is sent to the client are video commands which require less bandwidth than the remote control method, which sends video graphics which are already formatted. When running over the wide area, the connection can be made two ways. The first is to directly dial into the server using a proprietary asynchronous transport. This offers the advantages of requiring very little setup or footprint on the client machine, but limits client access to the application server only, just like remote control. The second method is to use a remote node connection into any remote node server, and to run the proprietary client over the top of the remote node stack. The advantage here is a connection that ex ploits the functions of remote node as well as remote control by offering excellent response of LAN applications that are executed on the applications server, as well as allowing users to concurrently run client-based applications. The difference between this and combined remote node/remote control clients is size. The multi-user application server client generally has a much smaller RAM footprint. From a management point of view, the centralized applications designed to run on the LAN require no change, and can be managed centrally in exactly the same manner as they are on the LAN. The application server transforms these bulky bandwidth hogs into a three-tier client server system, by centralizing the application, limiting the I/O intensive tasks to the application server, and making the client very thin. This is again similar to the remote control paradigm, except that because of the multi-user application server being a single machine with tight integration into the OS management, centralized support is easier. One thing that this combination of remote control and remote node cannot do in comparison to the combinations that come with traditional remote node and remote control clients is desktop remote control access. Because the multiuser application server runs on a dedicated box, any file or applications must be available on the LAN or on the server itself. Phone Company Remote Access Phone companies are beginning to get into the remote access business--offering soup-to-nuts remote node service. Be careful about the service levels, however. Some actually handle everything while others don't have a clue. Complete service from the phone company is like having an Internet service provider on site. The service should include all the central-site equipment, including modems and servers. Phone company personnel need to be on site and on call for 24/7/365 support. Client software, direct client support, and accounting and billing of client usage shou ld all be handled by the phone company. All that you should have to do is provide a router port for them to plug into. This is a new service for phone companies and while they all talk as if they are in this business, big differences do exist. Due diligence checking references and contractual service levels should shake out the hopefuls from the actuals. This will no doubt get better, but shop carefully for now. End January 16, 1996 Print This Page E-mail this URL