Thin 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.

Deploying thin clients is not hard, it is probably going to save you money and does not mean totally banning PCs and laptops

Thin 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 average desktop.

typical PC network

While 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, etc.

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 a configuration.

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 encrypted VPN.

Traffic flow for PC networks

Blueprints
Bearing 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 firewall.

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 the metafile.

Typical thin client network operation

If 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.

More upgrades
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 networks

The 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.