Interactive Network Design Manual

Client/Server Remote Access Solutions

by Bruce Boardman

Scope of This Article

Hundreds of products provide remote access service of one kind or another. We are going to focus on the
single largest segment of remote access, devices that support individual clients dialing over switched analog
lines to centralized LAN-based servers. Client/Server Switched Analog Remote Access is the most accurate
description but for brevity we will simply say "remote access."

"Remote Control" and "Remote Node" Defined

Remote access usually is divided into two main categories: remote control and remote node. Remote control
occurs when the remote user "takes over the keyboard" of a computer on the LAN. Applications are processed
on the LAN-based computer. The only traffic going to the remote PC is the screen and keyboard input/output.
Remote node access, on the other hand, connects the remote computer to the LAN as if it were a node on the
LAN. This means that all the traffic that would go to a LAN-based computer goes to the remote computer.

This difference has various consequences for remote use, as we will discuss below.

First Design Support, Then Buy Technology

A remote access system is made up of several technologies--clients, servers, modems, phone lines--a long
chain connecting remote users to the corporate LAN. None of the links in the technology chain are
overwhelming in their "rocket science", but none are so easy that it's a "no brainier" to choose and implement
the right one for you.

Perhaps the most overlooked part of remote access is the time and structure needed to support it. Like no other
system, remote access can eat hours if not planned for. It is not a server in a closet that "just works." It is a
tether of technology that binds users to the LAN, a connection that in their mind is just as reliable as what's at
their desk in the office. It is a rope of technology in which there is just enough slack to hang yourself.

When considering remote access, and trying to decide which approach is the right one, take some time up front
for planning. Step back and get a picture of what is driving the need for remote access in your organization.
Understand what makes users unique and what they share. Get a handle on the amount of support their needs
are going to require.

Once the reasons for remote access and the implied support are understood, you can find a solution whose
technology will meet the needs without burying you in support tasks.

Make a List
The fist step is to find out which users and applications need remote access. Keep in mind that you are building
a support strategy and picking the right technology, but don't feel constrained yet. The idea is to get an idea.
Let's start with the users.

The Users
Understanding the kinds of users, how they are grouped and where they will be dialing from are the key
ingredients.

Look at the grouping and number of users that need to be supported. The question is whether small groups that
need different applications exist or whether the small groups really make up a large group needing the same set
of applications. If the groups are segregated, separate departmental remote access solutions may make more
sense. If, on the other hand, a single large group or a number of smaller groups need the same resources, a
solution that will scale and lend itself to centralized control and support is the one to choose.

Where users are calling from is important, too. If the remote access is initiated from a stationary location like a
home, installs and upgrades need to be bulletproof, because they are likely to be done by the users. If, on the
other hand, roaming laptops are in the picture, installation can be performed and tested by your technical
organization in the safety of a lab or helpdesk.

Take a look at the kinds of users. Are they technical or non-technical? Technical users are less likely to need
hand-holding support but are going to demand the most from the remote access system in terms of flexibility
and access. The non-technical user will need the most support, in terms of setup and ongoing stability. The
non-technical user, if not planned for, is a real resource drain and the surest way to get a remote-access black
eye.

Are the users Big Cheese or Joe Cheese? While the Big Cheese is often a reason for exaggerated attention, this
is often handled individually and does warrant a full-blown helpdesk and 24-hour, seven days a week support.
Joe Cheese, on the other hand, does not mean that the support is of little importance. The only way to tell is to
look at the business deliverables created with the applications used.

The Applications
The applications destined for remote access will provide clues about the importance of remote access to the
organization as well as about which is the right technology to deploy. Importance is determined by looking at
the deliverables produced with an application. The kind of input/output (I/O) that an application generates
between the client and server will fit into either a remote control model, a remote node model, or some mix of
the two.

The first thing to do is to list all the applications that are likely to be run over remote access. Some examples
might be e-mail, file transfer, Web browser, database access, or terminal access to a timesharing or mainframe
system. Reasons for the access might include desktop file access, sales placement, keeping in touch while on
the road, or support of a production data processing system. Spread the applications and reasons out on the
kitchen table and begin to analyze them for business significance and I/O characteristics.

Determining how important an application is requires asking what kind of bottom-line impact it has, and what
new paradigms it will create. Applications such as access to desktops from home, file transfer, sales placement
and invoice tracking have fairly obvious value. Surfing the net for research or delivering a proposal by e-mail
may not.

Sometimes, an application does not have an obvious bottom-line impact, but it's still widely popular. This
causes a dilemma: because of its popularity, it will require a lot of support, but not supporting it will release a
tide of political discontent from the user community. Fortunately, leverage to justify such support should be
available from the divisions and departments most likely to voice discontent. The trick is to get in front of the
tide and ask the noisy to put their money where their mouth is. It may even be an opportunity to build support
for other more necessary applications.

New organizational paradigms can be achieved with remote access. Your organization may be trying to reduce
commuting to comply with federal guidelines or trying to populate new geographical regions without spending
much on plant and equipment.

Look for ways the work force can be more responsive to the customer, such as by providing on-site invoice
tracking. Look for flexibility, such as being able to meet a deadline even when a key participant is on the road.
Look for opportunities to provide benefits to workers, such as working at home or providing flex time, which
many may perceive as allowing work to get done while still "having a life."

Application Input/Output
The next step in sorting through the applications destined for remote access is to look at their I/O. The
bandwidth available in a switched remote access connection is small and must be used conservatively. How
applications use that bandwidth differs. Picking the right remote access technology depends on understanding
how this tiny resource will be used.

Many LAN-based applications assume the availability of several megabits per second of bandwidth. The
switched WAN links that remote access uses provide 115.2 kilobits per second at best, even with fully
compressed data and a V.34 modem. This more than tenfold difference matters less with a remote control
design than with a remote node approach, but there is no way around the fact that WAN links are much slower
than LANs.

Three Basic Models

While each application will have its own I/O patterns and may require analysis with a protocol analyzer to
completely understand, three basic client/server deployments generally determine what I/O you can expect.

Applications that load executables and data from a server to a client create huge amounts of traffic. Moving the
executable onto the remote workstation significantly reduces bandwidth needed. If this isn't possible this
bandwidth-hogging app will be handled best by remote control. Examples are Microsoft Windows and
Windows applications running from a server.

Applications that store executables on the client and only need to load data from the server are in the middle of
the bandwidth spectrum. This is common where files are accessed from a server with applications like FTP,
e-mail and Web browsers. They generally work pretty well within remote access' bandwidth limitations.

At the skinny end of the bandwidth needy are applications that load a client executable from a local hard drive
and make a transactional transmission to a back-end server, which only returns the results of the transaction.
This is the classic client/server model, and it's best suited for bandwidth-impaired remote node access.

What's To Support?
Once you've identified and understood the remote-access needs of your particular users and applications the
next step is to determine the support they will require.

Remote access systems fail for lots of reasons. That's the state of the technology today. Failures, and
complaints, will occur. Support happens. The idea is to minimize it. You know the old saying, "Don't sweat
the small stuff, because it's all small stuff." Well, in remote access the saying is, "Only sweat the support,
because it's all support!

Spending time up front understanding support cannot be overemphasized. Once a remote access solution is in
place the cries for help will start flowing in. By then, it's too late to walk away.
Understand how much support is needed, and how critical it is. Choose the methods that fit this need, and then
evaluate the technologies based on how they meet your support profile.

How Much?
To figure out how much support you are going to need, look back at your list of user characteristics. At one
end of the spectrum, users will share the same needs for applications and support, making for a large group.
At the other end of the scale, user groupings will have no overlapping needs, making for a lot of small groups.

For support to be successful it is important to make it the same for as many users as possible. The more needs
that are shared the better. If your user groups appear to be many and diverse, push to combine and standardize
needs. If this is not possible, work toward the ultimate in remote access support, let each user group support
itself. While this may not be as cost effective as centralized support, it may be the best you can do. It is
significantly more work to centrally support multiple remote access approaches and may well be an exercise in
futility.

Complete control over a remote user's environment is impossible, and providing support remotely is difficult.
Home desktop users will need a bulletproof install program to coexist with the unending number of software
and hardware combinations that family-used machines acquire. Laptops, while in no way immune to creative
software combinations, will probably be better known to you and can be evaluated and fixed in the shop.

It is unlikely that many users will be able to fix their own problems. What's more likely to happen is that some
technically challenged users will require support in greater proportion then either their number or their
applications warrant.

A beta test involving a cross section of the machines and key individuals can help determine what works and
what doesn't. Before making remote access generally available take the time to work out as many of the
"gotchas" as possible

Say When
Support will need to resolve some remote access failures quicker than others, and which need to be fixed
quickly usually depends on the application. A quick way to test an application's importance is to ask whether
or not a failure to connect can wait until the morning. If it can, you don't need to spend a lot of time building
round the clock bulletproof support for it.

A more methodical approach involves knowing the business or bottom-line impact of a failed connection for a
particular application. In addition to looking for direct monetary impact, also look for deliverables that affect
production schedules.

Do not fall into the trap of thinking that a large number of users with similar needs must need around-the-clock
immediate support. Focus instead on whether the applications in question need it.

How Ya Do That? Centralized Vs. Distributed - The Support Spectrum

Designing remote access support really means deciding about control. A centralized support model provides
more control than a distributed model. With centralized support, end users lose the flexibility to do as they
please as the support organization takes on responsibility. With distributed, less controlled support, users give
up unconditional hand holding for flexibility. There is no absolute right way. How you trade off control
depends on your users and applications.

Distribute To Avoid Support

There are good reasons not to centralize remote access. Of course, from the support group's point of view it
cuts down on the amount of work, but it really comes back to the users and applications.
The most obvious reason for a distributed approach may be a small number of users. Are applications and
security that localized to a single group? Is that group capable of it own support? Are the applications of little
importance to the organization? (Be careful here. This is a touchy subject which may require discrete
investigation.) If so, help the group choose and set up a desktop remote control system, make it clear that they
are in charge, and then forget it.

In some cases there may even be enough users to justify the whole "phone line, modem rack, central
approach" thing, but the applications or users' reasons for remote access just aren't that important, and you
know they never will be. This is outside the general trend, but it is possible. Carefully think through whether
or not you want to be in the remote access support business. It may be better left to those that are using it.

Moving remote access out into the hands of those using it really changes the role of the support group to that of
technical consultants. Evaluation and recommendation rather than deployment and control become the primary
responsibilities.

Centralize to Control Support

A centralized approach to remote access is popular because it scales well, supporting users and applications
while getting the most mileage out of sharing phone lines, modems, remote access systems and support staff.

Large numbers of nontechnical users often require hand holding, making a centralized, well trained help desk
worth the expense. If in addition to a large number of users, the applications being used are business critical, it
also makes sense to fold support into a production group like operations in order to insure "24 by seven by
365" support of not only users but the dial-up systems as well.

Large number of users can have a momentum of their own that might be better handled from a central point of
control. If your group has the know-how to support remote access, it may make support easier in the long run
to drive a centralized support policy rather than having to pick up the pieces of multiple distributed attempts.

While not a reason in and of itself, anticipated growth can sometimes be best handled through a centralized
approach.

Centralized Support Elements

Controlling and supporting the client software is the single biggest ongoing task in remote access support. It is
also the most underestimated. This is not necessarily because client software is bad. It's a result of having
users all over the place, changing their PC's environment by adding or deleting software. It's a result of
relying on the black magic of modems and the changing conditions of phone lines. It is not that the technology
is new or poor but that the pieces are open to user changes.

Supporting client software requires the following; A rock solid install program that is 100% percent
compatible, no matter the combination of equipment and operating system. This means doing controlled
releases of new versions of client software including performing regression testing of all previously
functioning applications. Even though client software may have been tested by the vendor, it is necessary to
test it in your environment. You also need clearly written documentation that is customized for your users. All
of this takes incredible amounts of time, but not nearly as much as having to respond to and reissue thousands
of copies of poorly tested client software.

A centralized approach to remote access also means folding the support of the remote access servers, modems
and phone lines into the operation's production environment. If you've decided on a centralized approach
because of how important the applications running over remote access are, you will need the 24/7/365 that
most operations group are geared up for. This will require the implementing technical group to provide design
and support of all the pieces needed by the operators.

The handoff of responsibility from the technical group to the operations group is handled through a production
control procedure. Production control is the process in which operations anoints a new service as production
and accepts responsibility for it. It is a pain to go through the red tape and finger pointing that is a part of
production control, but it is the only way to provide rock-solid access to users (and sleep to the technical staff).

You will need to provide thorough documentation and training to the operations staff. This needs to be in the
form of a cook book, tested and signed off by operations management and lead personnel. It is important to
think through the issues that have arisen during implementation and at which point technical support is to be
called. This is an evolving document and relationship that will change and improve only on the basis of this
formal relationship. The point is to remove personalities from the support equation in favor of procedures. It is
also important to note that while operations will accept responsibility for round-the-clock monitoring of the
remote access equipment, ongoing support will ultimately rest with the technical group.

Besides this bittersweet relationship between technical and operations a couple of benefits arise out of a
controlled central-site relationship. One is moving part the ongoing support expense from the technical
development side of the house to an existing operational infrastructure and budget. The other is a creating a
breeding ground for new entry-level technical expertise as well as a career path for operations.

A help desk will provide consistent end user support and feedback. Because the help desk sits between the
technical organization and the end user it is important that its workers are involved in the production control
procedure along with operations. Help desk personnel are the best place to go for client software regression
testing as they will have a much better idea of what problems users experience. Writing documentation and
designing client implementations should involve the help desk because of its closeness to the user. A help desk
is the first level extension of a technical group and should be expected to accept responsibility for the end
product and share in its success.

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, controlling 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 running 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
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 housed 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 management. 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 support organization can create a vanilla configuration that can be loaded to
aid in problem determination.

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 control, 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 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 exploits 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 should 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.