||This article needs additional citations for verification. (July 2008)|
A thin client (sometimes also called a lean or slim client) is a computer or a computer program which depends heavily on some other computer (its server) to fulfill its computational roles. This is different from the traditional fat client, which is a computer designed to take on these roles by itself. The specific roles assumed by the server may vary, from providing data persistence (for example, for diskless nodes) to actual information processing on the client's behalf.
Thin clients occur as components of a broader computer infrastructure, where many clients share their computations with the same server. As such, thin client infrastructures can be viewed as providing some computing service via several user interfaces. This is desirable in contexts where individual fat clients have much more functionality or power than the infrastructure requires.
Thin-client computing is also a way of easily maintaining computational services at a reduced total cost of ownership.
The most common type of modern thin client is a low-end computer terminal which only provides a graphical user interface to the end user. The remaining functionality, in particular the operating system, is provided by the server.
||This article needs additional citations for verification. (May 2013)|
Thin clients have their roots in multi-user systems, traditionally mainframes accessed by some sort of terminal computer. As computer graphics matured, these terminals transitioned from providing a command-line interface to a full graphical user interface, as is common on modern thin clients. The prototypical multiuser environment along these lines, Unix, began to support fully graphical X terminals, i.e., devices running X server software, from about 1984. X terminals remained relatively popular even after the arrival of other thin clients in the mid-late 1990s. Modern Unix derivatives like BSD and GNU/Linux continue the tradition of the multi-user, remote display/input session. Typically, X server software is not made available on thin clients, although no technical reason for this exclusion would prevent it.
Windows NT became capable of multi-user operations primarily through the efforts of Citrix Systems, which repackaged NT 3.5.1 as the multi-user operating system WinFrame in 1995. Microsoft licensed this technology back from Citrix and implemented it into Windows NT 4.0 Terminal Server Edition, under a project codenamed "Hydra". Windows NT then became the basis of Windows 2000 and Windows XP. As of 2011[update] Microsoft Windows systems support graphical terminals via the Remote Desktop Services component.
The term thin client was coined in 1993 by Tim Negris, VP of Server Marketing at Oracle Corp., while working with company founder Larry Ellison on the launch of Oracle 7. At the time, Oracle wished to differentiate their server oriented software from Microsoft's desktop oriented products. Ellison subsequently popularized Negris's buzzword with frequent use in his speeches and interviews about Oracle products.
The term stuck for several reasons. The earlier term "graphical terminal" was chosen to distinguish such terminals from text-based terminals, and thus put the emphasis on graphics. The term thin client was also not well established among IT professionals, most of whom had been working on fat client systems. It also conveys better the fundamental hardware difference: thin clients can be designed with less expensive hardware, because they have reduced computational workloads.
Thin clients as programs 
The notion of a thin client extends directly to any client–server architecture, in which case, a thin client application is simply one which relies on its server to process most or all of its business logic. This idiom is relatively common for computer security reasons. A client obviously cannot be trusted with the logic that determines how trustworthy they are, because an adversary can circumvent that logic.
However, in web development in particular, client applications are becoming fatter. This is due to the adoption of heavily client-side technologies like Ajax and Flash, which are themselves strongly driven by the highly interactive nature of Web 2.0 applications.
A renewed interest in virtual private servers, with many virtualization programs becoming commonplace, means that servers on the web today may handle many different client businesses. This can be thought of as having a thin-client "virtual server" which depends on the actual host in which it runs to do all of its computation for it. The end result, at least, is the same: providing of the computing service for many clients.
Single point of failure 
The server, in taking on the whole processing load of several clients, forms a single point of failure for those clients. This has both positive and negative aspects. On the one hand, the security threat model for the software becomes entirely confined to the servers. The clients simply do not run the software (think of them as a screen, keyboard and mouse - all keystrokes and mouse movements go to the server, which sends back the screen image). Thus, only a small number of computers (the servers) need to be rigorously secured, rather than securing every single client computer. On the other hand, any denial of service attack against the server will limit the access of many clients. But the server software is written with virtual machine technology so every client is isolated and a client crash is easily handled and rebooted. The single point of failure still exists, however. If the server crashes, data loss is possible. Therefore, backups are critical.
For small networks, this single-point of failure property might even be expanded. The hosting server can be integrated with file servers and print servers particular to its clients. This simplifies the network and its maintenance, but might increase the risk against that server.
In practice redundancy is provided both in the form of additional connectivity from server to the network as well as in the servers themselves, using features like RAID 5 or better, distributed server (multiple networked servers appearing as one server to the users), VMWare High Availability and Fault Tolerance or Citrix XenApp's load balancing.
Cheap client hardware 
While the server must be robust enough to handle several client sessions at once, the clients can be assembled from much cheaper hardware than a fat client can. Many clients have minimal RAM, some do not even have a hard drive. This reduces the power consumption of those clients, and makes the system marginally scalable, i.e. it is relatively cheap to connect additional client terminals. The thin clients usually have a very low total cost of ownership, but the need for a robust server infrastructure offsets some cost savings. Thin clients also are generally very low power and might not even require cooling fans, but the servers are higher power and almost always require an environmentally controlled air conditioned server room.
Client simplicity 
Since the clients are made from low cost hardware with few moving parts, they can operate in more hostile environments than conventional computers. However, they inevitably need a network connection to their server, which must be isolated from such hostile environments. Since thin clients are cheap, they offer a low risk of theft in general, and are easy to replace if stolen or broken. Since they do not have any complicated boot images, the problem of boot image control is centralized to the server.
On the other hand, to achieve this simplicity, thin clients sometimes lag behind thick clients (PC Desktops) in terms of extensibility. For example, if a local software utility or set of device drivers are needed in order to support a locally attached peripheral device (e.g. printer, scanner, biometric security device), the thin client operating system may lack the resources needed to fully integrate the needed dependencies. Modern thin clients attempt to address this limitation via port mapping or USB redirection software. However, these methods cannot address all use case scenarios for the vast number of peripheral types being put to use today.
Slow bitmapped/animated graphics 
Thin clients tend to be optimized for use with simple lines, curves, and text, which can be rapidly drawn by the client using predefined stored procedures and cached bitmap data. In this regard, thin clients work well for basic office applications such as spreadsheets, word processing, data entry, and so forth.
However, all thin clients suffer performance problems when large areas of the graphics display must be updated rapidly with high detail bitmap graphics, which may also need to be redrawn several times per second for animation purposes. In a few cases it may be possible to use a video stream that was already previously compressed such as MPEG or H.264 video, but many graphical programs such photo editors, 3D drawing programs, and animation tools require high detail uncompressed bitmaps to be displayed in order for the software to be used effectively. Graphics rich 3D games can be completely unusable on a thin client unless the updated screen area is kept very small or the overall screen resolution is very low, to reduce the amount of data sent to the client.
In an attempt to reduce network bandwidth, the server may try to compress high detail bitmaps on the fly before sending the data to the client, but this adds latency to the client-server communications, and may reduce user interface responsiveness. Many thin clients offer options to turn off various graphics rich user interface effects in order to increase performance, such as not showing the contents of a window while dragging or not displaying a desktop background.
Recent trends 
Ultra-thin or Clientless 
Traditionally, a thin client ran a full operating system for the purposes of connecting to other computers. A newer trend, sometimes called an ultra-thin client or a zero client, no longer runs a full operating system: the kernel instead merely initializes the network, begins the networking protocol, and handles display of the server's output. Basically the full OS is run in the cloud and then the cloud framebuffer is compressed with H.264 or HEVC and sent to the client. The client silicon is now much simpler and lower cost as all it requires is a video decoder and basic I/O.
Web thin client 
RTE client 
A Run Time Environment (RTE) client contains task specific applications (e.g. Mozilla Firefox for Internet browsing) and only the minimal (often customized) underlying and supporting code (BIOS, firmware, kernel, libraries, plug-ins, etc.) to run only those applications. It contains all and only the code needed to accomplish its specific task, thus it is more than a zero client but less than typical thin client computer. The RTE client does not have a general purpose operating system - it usually lacks shells (terminal windows), is not designed to be patched (updated online), has minimal connectivity to external resources, and is often found in read-only media (e.g. tamper resistant ROM chips, CD-ROM, etc.). Attempts to inject or run any other applications/processes/threads results in crashing the kernel (system). Due to the need to physically update the device, RTE clients are mostly found in stable environments demanding high security.
List of protocols used with thin clients 
- Appliance Link Protocol
- Citrix ICA
- Remote Desktop Protocol
- Secure Shell or SSH, an encrypted replacement for telnet.
- Virtual Network Computing
- X11, central to Unix windowing
- XML, HTML, or JSON over HTTP (Ajax)
See also 
- Blade PC
- Centralized computing
- Chrome OS
- Desktop Virtualization
- Dumb terminal
- Fat client
- Hybrid client
- Linux Terminal Server Project
- Multiseat configuration
- Smart client
- Terminal services
- UCS Thin Client Services (UCS TCS), an Open Source solution for the central management of thin client devices, independent of the device type
- Virtual Network Computing
- Windows PE
- X11, central to Unix windowing
|Wikimedia Commons has media related to: Thin clients|
- Nieh, Jason; Novik, Naomi &., Yang, S. Jae (December, 2005). "A Comparison of Thin-Client Computing Architectures". Technical Report CUCS-022-00 (New York: Network Computing Laboratory, Columbia University). Retrieved November 11, 2011.