What is Thin Client ?

The Net Impact of Thin Clients

The term "thin client" generally refers to user devices whose functionality is minimized, either to reduce the cost of ownership per desktop or to provide more user flexibility and mobility. Thin can denote a range of capability—that is, anything less than a full-fledged PC running a complete operating system, running local applications, and operating on locally stored data.
Various types of thin clients have existed in the past; X-terminals and diskless workstations are the most familiar examples. Recently, the term has been reinvigorated by relating it to several new Internet-oriented devices: the network appliance, the network computer, and the networked PC (which is really a standard PC that can also act as a thin client for some applications).
For any thin client, reducing the client role results in an increase in the server role in delivering complete applications. In a traditional fat client/server deployment (Figure 1), the client PC generally stores files and applications locally, enabling independent operation. The server is used to store completed files, making them available for sharing with other users, or to provide network services such as printing, faxing, and e-mail.



Figure 1. Traditional Fat Client/Server Deployment

Thin Client Models

There are two general models of thin client function. In the extreme case (Model 1 in Figure 2), the thin client device is simply an engine for user input and presentation. The server receives keystrokes and mouse commands generated by the client and provides screen display updates. The server provides all application, data storage, and communications functions. This model is sometimes referred to as server-based computing. It is the model used by Citrix and allows incremental migration to a complete thin client architecture through the use of a gateway server. The server looks like a fat client to traditional application servers, but provides a thin client extension over the enterprise network to user desktops.
In a slightly less extreme case (Model 2 in Figure 2), the server sends bits and pieces of data and applications to the client. The client operates on that information independently, provides client-based presentation and I/O, and requests more data or application functionality as needed. This distributed model is enabled by the Java programming language as well as other languages. Various forms of this model are becoming popular for dynamic interactions between Web sites and remote users.


Figure 2. Thin Client Models

By using thin client models, IT managers are trying to reduce operational costs. The Gartner Group has estimated the total cost of ownership (TCO) of a PC-based internetwork at almost $12,000 per year per desktop. Of this, only a small portion (about $2,500) is related to capital equipment costs (including software). Roughly $4,000 per year per desktop is spent on administration and technical support, and approximately $5,500 per year is spent by end users on nonproductive time associated with troubleshooting, customizing, or tinkering with their PCs and application software. The thin client architecture centralizes the control of the software, which simplifies version and configuration management, accelerates software upgrades and rollbacks, reduces the number of trouble reports, and makes trouble resolution more efficient.

Deployment Considerations

Two questions must be considered before deploying thin clients in any form:
• Are the server and data storage subsystems ready to support thin clients? Generally, server and data storage subsystems take on a greater role when thin clients are deployed. All aspects of the server farm should be examined to ensure readiness for thin client support. N-tiered application architectures, bigger servers, clustered/load-balanced servers, internal storage area network (SAN) bandwidth, and SAN-to-backbone throughput should all be evaluated to ensure the capacity of the system on the server side.
• Will the network support thin clients? In a thin client environment, network availability is paramount. If the network is down, users can't work on files, presentations, or reports, or even make local data entries for later synchronization. To ensure 24x7 network/application operation, end-to-end systems redundancy should be deployed along with instrumentation and applications to support rapid troubleshooting and automatic failover.
Because fewer operations are performed locally at the client, the use of thin clients results in a greater sensitivity to network latency. By implementing RMON-2 probes with related monitoring applications, the network manager can gain a detailed knowledge of application-related traffic flows between clients and servers, identify bottlenecks, and predict future trends. A variety of measures can then be considered to ensure that thin client application performance meets user expectations. These measures include:
• Deploying switching to the desktop
• Upgrading backbones to Layer 3 switched networks
• Increasing and managing bandwidth (especially WAN bandwidth) via techniques such as 802.1p traffic prioritization, application-aware switches, DiffServ, IP and ATM Quality of Service (QoS), and policy-based networking
The information contained in this document represents the current view of 3Com Corporation on the issues discussed as of the date of publication. Because 3Com must respond to changing market conditions, this paper should not be interpreted to be a commitment on the part of 3Com, and 3Com cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only; 3Com makes no warranties, express or implied, in this document.