A thin client is a computer system used to run applications
where most of the actual processing is done on a remote server linked
over a network. The local machine – the thin client – is simply
used to display the results in a way that is as close as possible to
what you might see when running the program locally. These local
machines are also called a slim or a lean client.
Thin-client systems in use at the World Trade Organization. Image courtesy nComputing
Thin clients are not new. They’re actually one of the most basic concepts in modern computing. We used to know them more conventionally as dumb terminals.
Such systems consisted of a teletype or CRT, connected to the computer in question via a coaxial cable. The terminal had little capacity of its own except the ability to print and send text.
Printers could execute certain auxiliary functions depending on their make and model, functions such as sending characters to punched tape or performing overprinting. CRTs could also perform certain display-manipulation commands—move the cursor, clear a line, insert or delete text, etc.—but these things were heavily device-dependent.
Few early version thin clients included anything beyond the most rudimentary printing or display behaviors, since these functions wouldn’t be supported consistently by their hosts. There were exceptions: in the 1970s, DEC’s VMS could support some special display-manipulation functions, but DEC only supported its own terminals (the VT52/VT100 series) for such functions.
Over the next two decades, the cost of computing hardware fell while its capacities increased explosively. Consquently, the common method of connecting to a given system evolved from a teleprinter or a character-based terminal to a full-blown computer in its own right. That meant all the resources of the PC -- its graphics, its memory, its ability to attach other devices -- could now be put to use by the remote system. Networking bandwidth and switching efficiency also started rising, making it possible to send that much more data over the network to begin with.
One way the use of local graphics and better bandwidth manifested itself was in UNIX’s X Window (now X11) display system. X allowed for a way to run graphical programs remotely: programs running on one machine could display their output interactively on another machine linked over a network. As long as both machines understood the X protocol in some way, it didn’t matter what OS they ran or even what the hardware was. The end result: systems in which running an application remotely didn’t mean you had to settle for mere text. The concept of the thin client began to gain serious business value.
Now, as the cost of hardware (and network bandwidth) continues to fall, there is increasing interest in centralizing computational work on server back-ends, and using thin clients of varying capabilities depending on the workload involved.
A thin client solution used to publish a graphically-intensive application (here, Microsoft Publisher) across a network. The small box to the left of the screen is the client. Image courtesy Wyse Technology.
In theory, most any application can be run on a thin client. In practice, getting the most out of a given app in a thin client setting may require functionality that isn’t available through the client device.
To that end, the kinds of applications you can use with a thin client depend on a number of factors: the thin client in question, the network bandwidth, what app-publishing functions are supported in the current protocol, whether hardware acceleration is available for various functions, and so on.
Different thin clients, therefore, support different workloads. For instance, the VNC protocol described above doesn’t (yet) natively support video streams. You could open a video player on a VNC-connected desktop, but you’d see at most one frame every second or so, even on a broadband connection.
On the other hand, you could run a web browser that supports Flash, connect to a remote video server, and enjoy full-screen H.264 video playback -- on the exact same network connection. It’s also possible to open a VNC connection in a web browser, since a VNC server can provide a Java-based browser applet that runs at just about the same speed as the binary client and supports most of the same features.
Leadtek's Virtual Desktop System can work as a PCI-e plugin card (shown here) or as a standalone device. Picture courtesy Leadtek
For reasons mentioned above, thin clients lend themselves most naturally to certain kinds of usage:
Any place where security is an issue typically benefits from some type of thin-client setup. Data is kept on the backend; the client only presents the user with whatever they are authorized to see, and tampering with the client generally only results in a broken client instead of stolen data.
Thin clients are also useful in public environments -- libraries, government offices, airlines, Internet cafés -- where many people may use the same machine, and there’s a need to reduce the amount of risk due to leftover data from previous sessions. The risk is not eliminated -- it’s always possible to “shoulder-surf” someone else’s work -- but it is reduced by dint of there being minimal data on the terminal itself.
Thin clients are well-suited to workloads where the actual work being done is not CPU-intensive, and requires only as much client feedback as would be provided by a web browser. In fact, many such thin clients may well be web browsers, since they provide toolsets to cover most of the user interaction you might need in such a scenario.
One common scenario for repurposing older PC hardware is to convert it into a thin-client system of some kind. Applications that would not run well on the PC itself could be published from a server to that PC across a thin-client connection, provided the app’s functionality wouldn’t be hindered that way.
Thin clients can be grouped into two basic categories: software thin clients and hardware thin clients.
A hardware thin client is a device that has been created specifically to run thin-client software and little else. It’s easy to compare it with the “dumb terminal” or “diskless workstation” of old, albeit with better graphics, but there are some other differences.
For one, the exact makeup of a hardware thin client varies. It could be an existing PC that’s been stripped down to do nothing more than run the client software, or a custom-designed piece of hardware that again does little more than connect to the remote host and perform the needed client display functions. One example of such a device is the nComputing system, a hardware thin-client mated with a server which allows dozens of users to be supported by a single desktop-class machine.
A typically small thin client systems, which draws no more than 15 watts of power by itself. Image courtesy Wyse Technology.
A software thin client is, simply, an application running on whatever host is available, whether dedicated (as with a hardware client) or just commodity hardware. It may use some of the abilities of the local host -- hardware-based graphics acceleration, for instance -- to better render the remote client’s interface.
But the exact choice of host doesn’t have to be a system designed solely as a connecting client—it can be a full-blown PC with its own workload, running the thin-client application in conjunction with other things.
Wyse was once a maker of terminals, but has since branched out into thin clients. Aside from connecting to remote hosts using ICA, RDP and VMware View protocols, Wyse has their own proprietary extensions to accelerate and enhance multimedia (including Flash) and multiple-display support across the wire. The clients are powered by a variety of operating systems depending on which model you use:Linux, Windows XPe, Windows CE, Citrix XenDesktop and their own proprietary ThinOS. (Wyse boasts that because ThinOS has no published API, this grants “high immunity from malware and viruses”.)
Leadtek’s normally known for making graphics cards, but they also
manufacture the Virtual Desktop System line of thin-client devices,
which use the Teradici PCoIP protocol. The VP 200H is an add-on card
which converts an existing system into a PCoIP client, while the VP
200P is a standalone device with low power consumption.
Hardware thin-client system, with connectors for a monitor, audio, and USB. Photo courtesy nComputing.
A line of hardware clients designed to connect over local and wide-area networks, with a variety of configurations (e.g., both single and dual display connectors). The remote host can be Windows, Linux or Solaris OS, as Oracle ships support for all three operating systems.
This is the graphical windowing system developed for current breeds of UNIX, as discussed above. X11 works on a very low level, however -- the core of the protocol doesn’t address things like windows, buttons, menus, style/theme controls, etc. -- so those things are typically handled by other components.
The emphasis with X11 has been on backwards compatibility and “provid[ing] mechanism rather than [user interface] policy,” so it’s still regarded mainly as a low-level transport protocol. X11 clients and servers exist for multiple systems apart from UNIX, which allows UNIX X11 apps to be published to, for instance, the Macintosh or Microsoft Windows.
Microsoft’s proprietary protocol for remote desktops and applications isn’t just used for thin client connections, although that’s one of its major functions. It can also be used to publish a specific windowed application to another system -- for instance, from a virtual machine to a physical one, as XP Mode in Windows 7 does for making XP applications available to the system at large.
The Citrix family of remote-application products works similar to Terminal Services, but supports both clients and application servers across multiple platforms. Citrix also works closely with the Xen hypervisor, so that virtual machines running under Xen (or individual applications running under those machines) can be published across the network.
Oracle’s (formerly Sun Microsystems’s) proprietary thin-client protocol, which allows their Sun Ray thin-client hardware to connect to Sun servers. A proprietary software client made by Oracle also exists, which allows any client that can run the software to connect to a Sun Ray / ALP server. (An open-source software implementation of the client hardware, called SoftRay, is also currently being developed in Java.)
Described by its creators as “a solution for interaction with virtualized desktop devices”, SPICE allows real-world hardware (from a thin client or otherwise) to interact directly with virtualized hardware on a virtual machine. Support for video, audio and client-hardware-accelerated features are all built into the protocol. The project is currently supported by Red Hat, who purchased the technology from its original developers and open-sourced it under the GPLv2 license.
Short for “PC-over-IP”, this is Teradici’s proprietary protocol for
remotely connecting to a virtualized machine. It can be used with
dedicated thin clients (“Zero Clients” in Teradici’s parlance); a PC
with an add-on card, such as Leadtek’s “Virtual Desktop System” lineup
of devices; or in software, such as in VMware’s View 4 application.
Short for Virtual Network Computing, this allows one computer to virtualize its desktop for another computer, regardless of the OS on either end. It allows for very precise rendering of the remote desktop, but at the cost of bandwidth and latency during major screen updates. Many extensions have been built into VNC to allow accelerated performance on specific platforms (e.g., Microsoft Windows), and a number of commercial (RealVNC) and free (TigerVNC) implementations exist.
The most common real world version of a software thin client might well be a web browser, especially given the amount of rich interactivity provided by most web sites. Google’s Chrome OS is one current example of a browser-based thin client, where the client contains just enough code to run the browser and any minor maintenance required on top of that (networking, local cache, etc).
The single biggest disadvantage to a thin client is its dependency on the network. Since everything a thin client does is provided across a network connection, the network becomes both a single point of failure and the single biggest performance bottleneck in the system. If the network slows down, experiences latency or cuts out completely, the client may do anything from lag to stop working entirely.
The exact construction of the thin client/server model in question can ameliorate some of the problems with a slow or flaky network. A web browser, for instance, can locally cache everything it downloads, although the size of the cache will vary depending on the capacity of the client hardware. Most anyone who’s browsed from their cache during a DNS outage will be familiar with how useful this is.
However, thin client dependency on the network remains. Also, networks are still many orders of magnitude slower than the slowest internal component in even a modest PC -- the cost of which may be comparable to a hardware thin client. This may limit a thin client’s cost-effectiveness compared to a more conventional local-workstation solution.