client computing can be efficient and secure if deployed correctly.
Graeme K. Le Roux tells you how to retool your network
for a thin-client implementation.
thin clients is not hard, it is probably going to save you
money and does not mean totally banning PCs and laptops
client computing can be more efficient and secure, yet many
companies loathe to implement it. One reason for this is the
perceived expense of rebuilding a network, or designing one
from scratch, to allow the deployment of thin clients on the
typical PC network
retooling for thin-client computing is not complex, it is
easier than one might think. But before embarking on thin-client
implementation, it is advisable to look at the limitations
of thin clients.
Thin clients are typically designed to replace the average
PC running bread and butter office applications such as word
processing, spreadsheets, e-mail and database front ends.
Thin clients are not intended to replace such things as workstations
running graphics intensive applications or supporting multiple
monitors. Also, while thin clients will support serial, parallel
and USB devices such as printers and PDAs, they won't support
more complex devices such as tape drives, CD-R/RW drives,
Importantly, thin clients do support modems and thus can be
used for dial-in telecommuting. Bear in mind though, that
since the remote thin client will rely on a network-connected
application server, and thus have to be online for the duration
of a work session, call charges may be rather high in such
If you are tooling for thin-client-based telecommuting, a
broadband Internet connection and a VPN, or a direct ISDN
or leased line service which does not incur time charges is
a preferable option. At the low-usage telecommuting end, the
most likely use of a thin client over a simple dial-in connection
is to provide support for a PDA. For example, HP's Jornada
family includes features like a built-in modem and a Windows
Terminal Server Client. This arrangement allows a user to
dial-in via, say, Microsoft Windows 2000 Server's RRAS and
work with all their standard office applications from a pocket-sized
device. Note that a direct dial-in link would be required
in this case because the PDA, unlike a laptop or DSL firewall/router,
will not support an
Traffic flow for PC networks
in mind these limitations and the characteristics of thin
clients, we can begin to implement changes which have to be
made to an average company network to accommodate thin clients.
(In this article, we will focus on Microsoft Windows based
devices, however, the discussion is generally applicable to
other thin client environments like those based on Sun's Hot
Desking technology and Sun Ray Network Appliances).
Figure 1 shows a typical company network in a multi-storey
building. Here, individual PCs and printers on each floor
are connected via UTP to one or more hubs, each having a single
fiber link, most likely full duplex, to a simple switch in
the building data centre. Also connected to this data centre
switch is a server farm containing the normal array of file,
print, e-mail and database servers and hosts along with a
Typically, the firewall has at least two other ports which
are connected to a DMZ containing publicly-accessible servers
and the router which terminates the company's Internet connection.
In this network, when a user opens a file, prints it and then
saves and closes it you get the traffic flow as shown in figure
2. This simple process involves transporting an application's
data file across the network back bone twice: a small metafile
once and then a rendered print file once.
The language in which a printer is programmed differs from
printer to printer so Windows uses a single metafile format
between print service clients (i.e. PCs) and servers; this
speeds printing as far as the client is concerned and avoids
the need to install numerous individual printer drivers on
all clients. Drivers for each individual printer are installed
on print servers and these are then used to render the metafile
as a print file in the appropriate language, such as postscript.
Rendered print files are generally considerably larger than
Typical thin client network operation
the layout of the company network is changed as per figure
3, which amounts to simply adding a few application servers
in the data centre, the existing PCs can be gradually replaced
with thin clients.
We can also simply add thin client software to the existing
PCs which will prolong their service life and thus save the
cost of a hardware upgrade cycle. Once thin clients are deployed,
print and save operation shown in figure 2 changes to that
shown in figure 4.
Notice that with the exception of the transmission of the
rendered print file to the users' local printers and traffic
between the thin clients and application servers, all traffic
is confined to the data centre. The traffic pattern between
the data centre and user's desktops changes from streams of
packets representing file opens and saves to mainly small
bursts representing user input and screen updates.
Ethernet handles this sort of traffic much better than the
sort of traffic which the network in figure 1 generates. Hence,
users are likely to perceive that the thin client system is
the system that provides better performance. It also means
that you may be able to hold off upgrading your cable system
and hubs longer than you might otherwise consider advisable.
When you do have to upgrade your network backbone and hubs,
there are several non-disruptive options to consider. First,
you can connect all the printers on each building floor to
a separate hub and connect that to the data centre switch
via a separate cable. This removes the printer traffic from
the network path between the clients and the data centre.
This approach can be a good idea in a PC network where there
is a heavy print load or if your printers use a verbose language
such as postscript.
Traffic flow for thin client
second option is to replace your hubs with switches which
support 802.1p and 802.1q. These two standards allow us to
assign the printer traffic to a specific VLAN and set a suitable
priority for it. This effectively allows us to reserve network
bandwidth for thin client traffic. This latter option is usually
recommended for supporting VoIP systems where QoS is required.
Of course you can split the printers off to a separate hub
and implement 802.1p and 02.1q but if your printing load is
that heavy, it is probably easier and more cost effective
to upgrade your backbone fibres to Gigabit Ethernet. That
is, replace ports on your data centre switch and replace the
hubs on each floor with switches which have a gigabit uplink
port, and then use 802.1p and 802.1q.
The basic components of a thin client system are thin clients,
application servers, and depending upon the size of your operation,
some network switches. These components come by easily and
are cost effective, particularly when you consider that a
rack mount application server 1 or 2U high can support one
hundred users without too much trouble.
Deploying thin clients is not hard, is probably going to save
you money and does not mean totally banning PCs and laptops,
so why not consider it next time you have to look at buying
a bunch of new PCs?
Graeme K. Le Roux is the director of Morsedawn (Australia),
a company which specialises in network design and consultancy
and writes for Network Computing-Asian Edition.
Check out www.sun.com.au for Sun Ray Appliances
and Hot Desking. For information on ThinStar thin
clients and ThinPath software, go to www.ncd.com.
Check out www.microsoft.com for Terminal server
information. Go to msdn.microsoft.com for RDP Protocol
information (search the library). For more on ICA
protocols, go to www.citrix.com. For more on Gigabit
Ethernet standards, go to www.10gea.org.
dog ate my word processor A distinguishing feature
of thin clients is that they do not run applications.
That happens on an application server. When you
open a file in, for example, a word processor on
a PC, the PC loads the word processor application
from its hard disk and the data file may be loaded
from a data centre server. In a thin client environment,
the word processor is run by an application server
from its hard disk, while the data file still comes
from the file server. What the user has on their
desk is effectively the GUI for the word processing
application. All keystrokes and mouse movements
are transmitted from the thin client to the application
server. The application server also sends screen
images-or rather, the instructions to draw them-back
to the thin client. The protocols used to do this
are a combination of Microsoft's RDP (remote desktop
protocol) and Citrix's ICA (independent computing
architecture), both of which run over TCP/IP. To
boost the richness of the thin client instructions
conveyed, vendors like NCD offer enhancements particularly
in the areas of sound and peripheral support (in
NCD's case via their ThinPath Plus software). In
Windows environments, most thin clients run Windows
CE, but without all the added applications. There
are some applications, however, which are commonly
installed on thin clients. Most thin clients have
a built in SNMP client and ping utility, which comes
in rather handy for troubleshooting. Units with
serial ports also often have built in PPP support
and a dialer utility that lets them support analogue
modems or an ISDN TA, which responds to the Hayes
command set. Some thin clients, such as PDAs have
in-built modems. In most cases however a remote
thin client is going to be attached via its Ethernet
port to a router/VPN server/firewall and something
like an ADSL link. Some thin clients also come with
a simple Web browser, which allows them to bypass
an application server for Web access. The logic
behind bypassing an application server for Web access
is that most users will not be looking at the same
page—and therefore processing the same Java scripts—at
the same time, and they are likely to be using a
Web proxy anyway. In contrast, an application like
a word processor is likely to be used by many people
at once. Which means that the application server
need only load the application's executables once
and maintain a separate data set for each user.
This is how the Microsoft Terminal Server can support
more than one hundred users.