Network Computingwww.networkcomputing.com

For starters, make sure that a user's notebook is equipped with an adapter that supports both Ethernet (you could get lucky!) and a modem, and, as a last resort, also supports a cellular phone interface. Make sure that the user doesn't plan to download a 15-MB file 10 minutes before his or her presentation. Emphasize that he or she should always test connectivity before it’s actually needed. Any information that you or your user can obtain in advance about the available facilities will help you plan your management and support strategies. Additionally, request to speak with a manager or the person in charge of the property’s telecommunications services. However, it’s not unusual to find that these services have been outsourced. Make sure that your users obtain all costs up front, including installation, if they need something other than in-room analog services. Please note that sometimes "available" doesn’t mean "in place," and that extra fees may apply.

Another good idea is to have your users acquire a reliable, removable and portable mass storage device for transporting large files. Sure, they’d prefer having a huge hard drives on their notebooks, but those drives won’t help them if the laptops are damaged in transit. Having something that can be quickly reconnected to a desktop or other laptop will help prevent a failed notebook disaster. Be sure it uses something universal between notebooks and desktops, such as a parallel port or USB-enabled drive. Should a user experience a failure, he or she can quickly move to something else in an emergency. Additionally, encourage your roving users to take as many files along with them as possible instead of downloading them from your network. Make sure they know which types of files are and aren’t portable. Many users mistakenly believe that their files can be accessed only via some kind of network connection (even remotely via modem). They don’t realize that a file can be made portable merely by loading its parent application locally. This isn’t the most elegant approach, but again, we’re talking about contingencies and disaster avoidance. Pretty isn’t as important.

Finally, what do you want to host at your site for them to connect to? If you're directly connected to the Internet (dedicated 24x7), you'll have ample options available. If not, you'll need to install a dedicated terminal server (a requisite if you're going to have a lot of remote and mobile end users), a modem in a server for direct RAS-style connections, or a modem on the user's stationary PC for a "remote-control" style solution. We'll discuss these options as we progress, but you should start thinking about them now. A good source of useful information can be found at:

• Client/Server Remote Access Solutions by Bruce Boardman
  http://www.networkcomputing.com/netdesign/remacc1.html

Application Usage and Quality of Service

Is the user going to need an application that resides on the central network, or will he or she need occasional access to files, resources and e-mail? Your answers will determine your bandwidth and latency issues and tell you if you’ll require a more sophisticated client/server or thin-client application approach, or something as simple as a PoP server account with limited RAS authentication for occasional file down/uploads.

Any kind of interactive application usage is not a good idea for your mobile users. It can be done, but it’s difficult to do well. Some common examples of an interactive application would include database access, and account entry (any type of situation where a client is open and actively talking with a server). This is an area where you must know and understand the specific dynamics of the expected type of traffic. A well-designed, thin-client technology really stands out here, but a user that expects to actively edit a large spreadsheet across an anemic connection is going to be in for a rough ride. You can find excellent information on this subject at:

• Managing Mobile Code by Peter Rysavy
  http://www.networkcomputing.com/netdesign/1017mobile.html

Clearly, you can’t plan on consistent QoS (Quality of Service) from a remote, analog, dial-up user. So many elements are out of your control and you have very few options available to remedy the problems this type of user is likely to encounter. Not to mention your having to deal with a client that is only able to squeeze out a few kilobits of connectivity when the application requires a very low latency on the pipe or at least several kilobytes of room to work in. In most cases you'll be dealing with finicky modems, hotel switchboards and long-distance carriers. This applies to users that access your network courtesy of the Internet, as well as your direct dialers.

The ideal method of dealing with these particular issues is to select the best equipment available that has been tested with your selected ISPs or your own direct access gear. You can't control the hotel's switchboard or the LD circuits between you and them, but you can pretest the equipment you're supplying to your user, choosing the most compatible configuration. Don't always choose the equipment that connects the fastest; pick the products that establish the most reliable connections. Perform "endurance" tests, checking how long a device can remain connected. Fast connection rates are no indicator of overall performance. Simply achieving the highest data rate possible isn’t the only element you need to consider; faster data rates over analog circuits are more prone to encountering data errors, and may force more retraining of the modem. A slower but more consistent connection will provide better overall performance than one that is faster on connect, but must continually retrain. Allowing for full autonegotiation is better than trying to force a high data rate that causes the connection to constantly hiccup midstream. You also can’t trust the initial connection speed reported by your dial-up client; most only indicate the initial rate. They don’t demonstrate the whole story as your modem retrains itself into a downward spiral.

Your options significantly improve, however, with a remote user dialing in from a fixed location, such as a home office, especially if the user is local. If he or she is dialing directly into your network, you have some control over the amount of bandwidth he or she can receive. Since the user is located in one spot, he or she can choose the connection type instead of accepting the standard solution (like the mobile remote-access crowd must do). You can have ISDN lines installed for your "bandwidth-hungry" group (provided you’re able to support that interface with corresponding BRIs or PRIs feeding your terminal serving equipment and that the service is available in your area).

Many client/server applications are designed to work with headroom of 64 Kbps to 128 Kbps, with space to spare. If you’ve got the resources to consider thin-client technology, such as Citrix’s Winframe or Microsoft’s Terminal Server, and your applications fit into that model, this solution is a good way to go. Thin clients operate with very little bandwidth and considerably improve interactivity for remote users. They also provide virtually complete control over your end user’s environment if you’re able to use diskless workstations; you simply feed them their desktop, and they have no way of permanently changing the configuration. An excellent review of this technology can be found at:

• Windows-Based Terminals: Construction in Progress by Dave Molta
  http://www.networkcomputing.com/920/920r1.html

If you prefer that your users access your network via the Internet, do a little research before selecting an appropriate ISP. Bigger is not always better in this case. Ideally, your user should dial into the same ISP that your corporate bandwidth originates from, thereby alleviating the amount of network (router) hops that will occur to reach you. If you’re both using ISP X, there should only be a few hops because the connection never actually goes out onto the Internet: All the traffic is carried on the ISP's internal backbone straight to you. An additional benefit of routing your remote users to your network via the Internet is that your internal support will be reduced. You’ll avoid the headaches and costs of having to support your own private dial-in pool. With no additional lines and no additional equipment, your existing equipment should be fine, provided that you have good security.

A final word about remote-control software–i.e., software that lets a user dial in (either via a modem, or via IP) and control a selected host. This approach is a terrific alternative to thin-client technology because it lets a remote user completely control a local host machine and have all transactions occur on the local machine. The software only needs to coordinate screen updates across the connection, which can typically be done quite nicely, even over the slowest of connections. Your user can work on bloated applications from home or on a machine located at the office, and not use the bandwidth that would have otherwise been required to transport the actual data back and forth. Only screen updates are required to cross the connection. One disadvantage is that this is resource-intensive in terms of distributing workstations. If a user already has two computers, one mobile and one on your network, then this is a great solution. If they don’t, then you’ll need to dedicate one for that user. You can see how this would quickly deplete your budget. Security isn’t as much a concern as it used to be because most products allow for various forms of end-to-end encryption. Therefore, don’t let that stop you from investigating the feasibility of remote-control software.