Section 12.1. The Role of Thin Client Computing

12.1. The Role of Thin Client Computing

Thin client computing can be a great way to stretch limited computing budgets and simplify system administration headaches. It's not the best solution to all problems, though. Deciding when to use thin client computing requires understanding the different forms it can take and the advantages and disadvantages of these forms.

12.1.1. Types of Thin Client Computing

In practice, the term thin client computing covers a range of configurations, from extremely simple thin clients that use powerful remote login servers to much more capable thin clients with substantial onboard software that uses remote login servers for file storage and software not provided on the thin client. In fact, it can sometimes be difficult to draw the line between thin client configurations and traditional desktop systems that use remote login servers for occasional uses or specialized tasks. Different people can draw this line in different places or by using different definitions. For instance, one common definition uses the presence or absence of a hard disk on the client as a deciding feature: if a system has no hard disk, it's a thin client. Not all thin client definitions include this feature, though.

In practice, thin client computing is essentially a return to an older model of computing that was common in the 1960s through the 1980s, in which dumb terminals were the primary means of accessing the mainframes and minicomputers of the day. Typically, employees, students, or other users would use the dumb terminals (which provided text-only displays) from their desks or from public computing environments. After the advent of X for Unix, some dumb terminals were replaced by X terminals, which were essentially dumb terminals capable of running an X server. In fact, X terminals are still available today and can make excellent thin clients for Linux systems.

An X terminal runs an X server, but in the language of the thin client world, the X terminal is a thin client. This is yet more confusing fallout from the peculiar client/server relationship in X, as described in Chapter 11.

Although you can use old-style dumb terminals (or computers that run terminal emulators to stand in for dumb terminals) with Linux, modern thin client computing relies on GUI remote login tools to run GUI programs. Chapter 11 describes two protocols that are commonly used in thin client computing, but the range of possible protocols is actually wider than that:

The X Window System

X can make an excellent thin client protocol when accessing Linux (or other Unix-like OSs). You can run Linux and X on older or stripped-down systems or use dedicated X terminals as thin clients. You can't easily use X to access Windows servers, though, except in limited ways.

VNC

VNC, or the Remote Frame Buffer (RFB), as the protocol is more properly known, is a useful thin client tool. Linux can function as a VNC server or client, enabling you to reuse old computers. You can also run a VNC server on Windows systems to provide remote access, although VNC doesn't provide multi-user access to Windows. (Using VNC to access Linux isn't so limited.) Some dedicated thin client appliances support VNC, so it can provide remote access to Linux from such thin clients.

RDP

The Remote Desktop Protocol is Microsoft's favored thin client protocol and is supported by Microsoft's Terminal Server software package. Linux RDP client packages are available, such as rdesktop (http://www.rdesktop.org) that lets you configure a Linux system as a thin client for a Microsoft server.

ICA

The Independent Computing Architecture protocol is favored by Citrix, which provides tools to access Microsoft Windows servers using thin clients that support the ICA protocol. Citrix (http://www.citrix.com) provides a free ICA client for Linux, so Linux can function as a good ICA thin client OS.

Typically, to provide remote access to Linux systems, you'll use X or VNC. To access Windows systems, VNC, RDP, or ICA will work, although only the latter two protocols support multiuser access. (Technically, changes to the underlying OS enable multiuser access; the protocols simply connect to that new feature.) Thus, RDP and ICA are the protocols of choice for thin clients accessing Windows servers.

12.1.2. When to Use Thin Client Computing

This chapter has already alluded to some of the advantages of thin client computing, namely hardware cost savings. This isn't the only reason to use this approach, though. Here are some common advantages of thin client computing:

Hardware cost

By recycling old computers as thin clients or buying new stripped-down computers or dedicated thin clients, you can reduce your expenditures on new desktop systems and upgrades to desktop computers.

Reliability

Thin clients, being much simpler than conventional desktop systems, are less likely to break down, all other things being equal. This can reduce the need for tedious hardware troubleshooting sessions.

Reduced noise and power consumption

Particularly if you use dedicated thin client hardware or old computers without hard disks, thin clients are likely to be quieter and consume less power than full desktop computers. This also results in less heat, which can help lower air conditioning bills. One partial exception to this rule is if you reuse old CRT monitors rather than buy new LCD monitors. CRT monitors consume a lot of power compared to new LCD monitors, replacing CRTs with LCDs can further reduce your power consumption.

Decoupling users from hardware

In a thin client environment, any user can use any thin client computer. Users see their own desktop environments and their own files, no matter which thin client is used. This feature can be great in public computing centers or when you want to upgrade hardware or move users between offices.

Administrative effort

Administering a single login server computer and dozens of thin clients is typically simpler than administering dozens of desktop computers.

Security

In some sense, this advantage is a corollary of the last one. Simple thin client computers are less likely to become infected by worms or otherwise compromised than are typical desktop systems. This advantage is particularly great if the thin clients are simple dedicated units with their OSs in ROMs or if they can boot from files stored on a network server. If you use Linux systems with their own hard disks as thin clients, an intruder might be more likely to gain access to and modify the clients. Thin clients can also benefit by the fact that it's seldom necessary to give them public IP addresses; they can reside on entirely private subnets that link only to your local servers and to each other. This can be even more secure than a conventional desktop behind a network address translation (NAT) router, because the thin clients can't initiate outside connections (say, because of a viral infection).

Ultimately, most of these advantages boil down to cost, either for hardware or for labor in maintaining all of a site's computers. These advantages are offset by disadvantages, though, some of which are in the same areas as the advantages:

Hardware cost

The cost benefit on the client is at least partially offset by the fact that you'll need to invest more in the server or servers that users will access. The login server must typically be substantially more powerful than individual workstations, although precisely how much more powerful depends on your site's computing needs. Light uses, such as word processing, may need a server scaled to the needs of a typical user plus a small increment in RAM and CPU speed for each additional user. CPU- or RAM-intensive tasks such as running scientific simulations may not work well at all with a centralized approach unless you invest in a very powerful server. As a general rule of thumb, a high-end IA-32 system (say, one that sells for about $3,000) can usually support about 30 users.

Reliability

Although thin clients are likely to be more reliable than individual desktop systems, this approach is essentially one of putting all your eggs in one basket. If the login server computer or your main network infrastructure fails, no user will be able to do any work. For this reason, you should be particularly careful in buying or building a login server for a thin client environment; buy the most reliable hardware possible, and whenever possible, employ reliability-improving tools, such as a Redundant Array of Independent Disks (RAID) array. Keep backups of your data and have backup hardware on hand so that if a critical server hardware component fails, you can quickly replace it. Using server clusters or having redundant servers can also be useful techniques to improve reliability. Also, if you use old PCs as thin clients, their reliability advantage over new desktop systems may evaporate, but the thin clients are cheap and easy to replace should they break.

Local devices

Using some types of local hardware devices, such as sound cards, scanners, and CD-ROM drives, can become tricky in a thin client environment. Solutions to these problems do exist, but they often require extra configuration to work well. For instance, you might need to configure a thin client computer as a file server to give users access to a local CD-ROM drive.

Thin clients can be deployed in any number of environments, from two-user small offices to academic or corporate sites with thousands of users. Depending on the type of work being done and the server's speed, a single server can support anywhere from a handful of concurrent users to several dozen; thus, large sites are likely to have multiple servers.

The thin client approach tends to work best with applications that are relatively undemanding in terms of the CPU and display. CPU-heavy tasks such as raytracing or scientific simulations work best when all users have their own CPUs, and graphics-intensive tasks, such as watching real-time video, make huge demands on network infrastructure when deployed on thin clients. Tasks that are better suited for thin client environments include word processing, light spreadsheet use (so long as spreadsheets aren't doing extremely lengthy computations), reading email, web browsing, using a corporate database, and other basically textual tasks. These jobs require users to read for long periods of time, and much of the interaction involves typing, which changes the onscreen display slowly.