Archives ||  About Us ||  Advertise ||  Feedback ||  Subscribe-
-
-
  -  
 
 Home > Focus ; Thin Clients
 Print Friendly Page ||  Email this story
Thin design

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.

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

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

 
     
- <Back to Top>-  

© Copyright 2001: Indian Express Group (Mumbai, India). All rights reserved throughout the world. This entire site is compiled in Mumbai by The Business Publications Division of the Indian Express Group of Newspapers. Site managed by BPD