Can a Hybrid Network Work for Your Enterprise

Get the most from thin clients

Thin-client technology--the idea of splitting processing between a client and server for all applications--is a hot topic. Thin-client enthusiasts say the technology applies to every computing situation. Thin-client debunkers say the technology is not worth the time and effort required to implement it. The truth is somewhere between these extremes.

A better solution than trying to make thin clients work for all situations, or deciding that thin clients won't work in any situation, might be to design a hybrid network. On such a network, some computers are thin clients and others are not. In addition, some applications are servercentric, and other applications reside on individual computers to take advantage of local CPU power and decreased network-delay latency. Hybrid networks are complicated to administer--you must remember which applications are loaded where and what resources are available to them. But hybrid networks can help you make the most of available resources and use thin-client technology to fit your needs, rather than mold your network to fit thin-client technology. (To read about one company's thin-client implementation, see "IBM Treats Guests to Thin-Client Computing," page 171.)

To help you get the most from thin-client technology, I'll deconstruct thin-client computing and show you how to evaluate the requirements thin clients demand. You can then decide how to work with these requirements to design an optimal hybrid network. I'll describe what today's thin-client technology looks like and what you'll need to understand about the particular limitations of the technology. Then I'll give you tools to help you evaluate servercentric applications to use with your thin clients.

Thin-Client Models
Thin-client computing isn't a new concept but a return to the mainframe model. Some people use this fact as a stick to beat thin clients with, but the mainframe model is a valid one. Fewer wasted CPU cycles, centralized administration, and pooling of resources are not bad ideas. That compute-heavy applications make a mainframelike approach unworkable in some circumstances doesn't mean such an approach is not a good idea in other situations.

The predominant thin-client model today is the Windows terminal. In this model, which Citrix's WinFrame technology and Microsoft's Windows NT Server 4.0, Terminal Server Edition use, applications run on the server, and the server downloads images of the interface to the client. The client might be a true Windows terminal such as the Wyse WY series, or it might be a PC. Either way, the client devotes its resources to drawing images on the screen. The protocols that Windows terminal solutions use don't all work in the same ways, nor do these protocols all produce the same results. Citrix's Independent Computing Architecture (ICA) protocol, for example, permits more fine-tuning of application publishing and accommodates a wider array of clients than does Terminal Server's Remote Desktop Protocol (RDP). However, the idea behind the Windows terminal model, which Figure 1 illustrates, remains the same--client resources are devoted to bitmap display.

New Moon Software's Liftoff application, released in April 1998, introduced a second model of thin-client computing. In this model, the server publishes individual applications. When a client runs such an application, the application's processing divides between the server and the client, with the presentation APIs running on the client and the kernel APIs running on the server, as Figure 2 shows. The difference between the Liftoff model and the Windows terminal model is in the way each model presents images. Liftoff downloads drawing instructions to the client, and the client processes the instructions with mouse clicks and keyboard strokes. This model results in less data traveling the network, but requires the client to have more processing power than is the case with the Windows terminal model. In both thin-client models, however, the goal is to concentrate resources on the server.

Thin-Client Limitations
The most obvious limitation of thin-client computing is that it creates a strain on nonmainframe servers. The less power you allow clients, the more power you must give to servers. Thin clients plugging in to a server must contend for limited resources in the following areas.

CPU time. On a traditional LAN, the usual ratio of clients to CPUs is one to one. This proportion results in wasted cycles, because most users don't need a CPU 100 percent of the time. Most vendors of thin-client solutions estimate that you can run about 12 clients to 15 clients per server CPU, although various computing situations might give you a higher or lower ratio. In a situation in which CPU utilization is low and applications are not CPU-bound, a CPU can support as many as 50 clients. In a situation in which CPU usage is very high and applications are CPU-bound, the ratio of clients to CPUs is much lower.

RAM. In a Windows terminal environment, server RAM--rather than client RAM--stores user data. Fortunately, memory prices are low, because you need a lot of server RAM to run Windows terminals. (A tool such as the Microsoft Windows NT Server 4.0 Resource Kit's Process Viewer shows you how much virtual and physical memory one application requires.) When Windows terminal users plug into an application server, run separate instances of their applications, and store file data in memory, server memory requirements quickly become administrative problem areas as the server increasingly must support fat applications and fat data files.

Users accustomed to the improved memory and stability of Win32 operating systems (OSs) over earlier OSs are likely to open applications and leave them open. Thin-client networking might introduce the necessity to train users to close applications when they're finished with them, rather than minimize the applications.

Virtual memory addresses can become another problematic area for administrators of thin-client networks. NT 4.0 supports a 4GB address space. Suppose 100 users, each holding 30MB of data in memory, plug in to one server. When you add the server's memory requirement, you'll be perilously close to running out of virtual memory addresses altogether. If you run out of addresses, the system will generate Stop errors at best. At worst, the system will crash.

Network access. Applications run on the server in the Windows terminal thin-client model, but application images download to the client and mouse clicks and keyboard strokes upload to the server. The excess traffic this divided operation causes creates a less responsive system, so it's important that thin-client solutions, particularly those following the Windows terminal model, keep the number of bitmaps the server sends to the client to a minimum. Network traffic reduction is even more crucial when the client and server are on a slow network connection such as a WAN.

Server components. Designers of 3.5" drives and CD-ROM drives, serial and parallel ports, and related components did not originally intend that several people would share these components at one time. Because of this design assumption, some applications might have a hard time negotiating with additional instances of applications for access to peripherals.

Server objects. When multiuser NT sessions run on a server, as happens in the Windows terminal model, each client session runs in its virtual machine, independently of other client sessions. However, the design of systemwide resources such as the Registry does not allow for processing instructions from more than one source at the same time. Few applications perform well under these circumstances.

Choosing Servercentric Applications
Most Win32 and Win16 applications run on a thin-client network, but some applications work better in thin-client computing than other applications do. How can you evaluate applications for thin-client suitability? You can begin with the Microsoft white paper "Optimizing Applications for Windows NT Server 4.0, Terminal Server Edition" (http://www.microsoft.com/ntserver/basics/techpapers/default.asp). This white paper is a set of guidelines for designing applications to work with Hydra beta 1 (Terminal Server's prototype). The guidelines still work well for choosing applications for thin-client networks. If you are evaluating applications that don't follow these guidelines and your clients will support running applications locally, consider loading onto the client the applications that don't follow the "Optimizing Applications" guidelines.

Keep in mind that the design of some applications causes those applications to assume that the proportion of users to machines is one to one. Although this assumption doesn't always present a problem in single-user environments (if user profiles are enabled and different people use the same machine, improperly stored data might make the profiles incomplete or confused), it causes problems in multiuser environments. To prevent these problems, store any changes an application makes to the Registry in HKEY_CURRENT_USER. If instead you store the changes in HKEY_LOCAL_MACHINE, the changes will be visible to all users. In addition, users who run applications from the server will be unable to keep personal settings, because when other users make subsequent changes to personal settings, the new changes will overwrite the old changes. Finally, when user-specific information is available to anyone using the server, security is compromised.

Following are specific features that can help you evaluate applications for a hybrid thin-client network. Place applications on the server that operate well in a thin-client environment, and load all other applications on client machines. For instance, if you want to run Netscape Communicator, you can--even though it stores information in HKEY_LOCAL_MACHINE. Simply load it on your clients. When you do so, you can still run Microsoft Office from the server as a thin-client application. Figure 3 shows an example hybrid network.

Store local data in global locations. Anyone who's ever been annoyed at applications that insist on storing information and DLLs in the system directories will be glad to know that Microsoft's new guidelines for developing Win32 applications emphasize that applications store information only in application directories. In multiuser environments, it's important that applications store personalization information not only in the user-specific areas of the Registry but also in the user-specific areas of the disk. An application you intend to run in a multiuser thin-client environment should store user files such as custom dictionaries in the user's home directory on the server.

Keep extraneous visuals to a minimum. Because the brunt of image processing in thin-client computing takes place on the client machine, away from the main concentration of system resources, make every effort to reduce both the information flowing to the client and the processing the client must perform. A good application for a thin-client network is one that does not show unnecessary animations or images. Animations use computing cycles, and in a multiuser environment, you need all the spare cycles you can get. Some applications cache bitmaps, sending only updates across the network (e.g., every time you move your mouse, the application sends only the cursor movement to the client, not a complete redraw of the screen).

Lock file and database records. Choose applications that let you lock in-use files that more than one user can access simultaneously. Locking these files prevents simultaneous accesses from corrupting the files.

Recognize single-user names. A server-based application that relies on IP addresses or computer names to direct messages to multiple users looks for an IP address or computer name to send messages to. Such an application can lose its messaging function in a thin-client environment because the application thinks it's attempting to talk to itself when it sends a message to an IP address or computer name. Windows Chat has this problem when it sends messages to a computer name and finds the server's computer name. The NET SEND command-line utility does not experience this problem because it manages communications between usernames. If you must use an application that doesn't manage messaging by username, run the application from client machines.

A Final Note on Client/Server Applications
It's strange but true that client/server applications might not work well in all thin-client environments. In the Windows terminal model of thin-client computing, applications designed with a client and a server component run more poorly than applications designed for a single platform. The reason for this difference is simple: Client/server applications are designed for distributed computing, and when they're forced to run in a thin-client environment in which they display only updates to clients, they will be short on processing power. You can get around this limitation with a powerful server, but you must be aware of the limitation if you use client/server applications in your hybrid network.