Windows Terminals vs. Network Computers

A thin-client bestiary

If you've been following the public discussion about thin-client networking, you're familiar with thin-client concepts. For example, most data processing takes place on the server end, and image rendering takes place on the client end. You might have the impression that the client-side hardware doesn't matter much, but this impression doesn't necessarily reflect truth. Sometimes, depending on what you expect a thin-client device to do, the client-side hardware's capabilities matter a lot. In this article, I'll contrast Windows terminals and network computers (NCs), two thin-client devices that people often have trouble distinguishing between. (To read about a possible third thin-client type, see the sidebar "Where Do NetPCs Fit in Thin-Client Networking?" page 108.) I'll describe the uses each device addresses and the hardware each device requires. Not all thin-client computing devices are created equal, nor did their developers intend them to be.

Network Computers
The first thin-client computing devices to hit the market were NCs, and they took advantage of the then newly available Java technology. The Open Group's NC standard isn't limited to terminal-like devices but can include any product (from desktop to palmtop) that runs Java applications either in a networked environment via IP or, more rarely, in a standalone environment. NCs typically operate as Internet computers: The Open Group's standard requires NCs to support Web-page interpretation, download and run Java applications from Web pages, and send (but not receive) mail. Support for FTP and Telnet sessions is optional. In other words, an NC's primary mission is to be an Internet (or other IP network) client, offering optional support for downloading files or running applications from a terminal server. NCs include the following hardware devices:

An NC isn't necessarily limited to the devices on this list. For example, an NC might also support local hard disks or PC-card slots. However, all NCs must support these devices.

The devices on the NC hardware list are common to most thin-client computers. So what makes an NC unique? The answer is Java support. NCs are, to use a current popular term, lean clients rather than thin clients, because NCs can execute applications—albeit small Java-based applications—locally. A true thin client, such as a Windows terminal, can't execute applications locally but must execute all applications—even Java-based applications—on the terminal server to which it's connected. Another defining characteristic of an NC is that it must use the TCP/IP suite of protocols: IP for main data transfer, TCP for error control, and UDP for name resolution via a DNS server. NCs that follow the standard don't use IPX/SPX.

Although media hype about the NC possibly replacing the PC (similar to current hype about thin-client computing possibly replacing the more common LAN networking paradigm) occurred initially, such a scenario isn't realistic—NCs are too limited functionally to seriously rival the more flexible PC. NCs were potentially in a position to replace PCs people were using for specialized functions that Java applets could handle. Thus far, NCs haven't replaced PCs, but replacing PCs is the NC's goal.

Windows Terminals
NCs aren't exactly dead, but neither have they taken off according to expectation, probably because the Java language is still a niche technology. As thin-client networking continues to develop as a viable alternative to the fat-client paradigm, Windows terminals, or some version of Windows terminals, are the most common choice for network clients.

Narrowly defined, a Windows terminal is a network-dependent thin-client device that supports the local output of applications that run on a terminal server that's running a multiuser version of Windows NT (e.g., Citrix WinFrame, Windows NT Server 4.0, Terminal Server Edition). A Windows terminal device includes a CPU, some amount of memory, network and video support, and both a keyboard and a mouse or their equivalents. A Windows terminal device boots from a mini OS in locally storedROM—nothing more is necessary to run applications from a terminal server. Because applications don't run locally, a Windows terminal doesn't need as much memory or CPU power as an NC possesses. However, both NCs and Windows terminals put older PCs to shame. A typical Windows terminal might have a 100MHz CPU and 32MB of memory; as recently as 4 years ago, when Windows 95 hit the market, a reasonably well equipped PC had 8MB of RAM. Thin does not imply anorexic.

However, the narrow definition of a Windows terminal doesn't necessarily reflect reality. Many Windows terminals aren't limited to locally displaying applications that run remotely. Some devices that vendors sell as Windows terminals support local execution of Java applications, others have built-in applications (such as a Web browser) that run locally, and still others have PC-card hard disks. Nor are Windows terminals protocol-dependent to the degree that NCs are. Although the RDP display protocol that Terminal Server natively supports is TCP/IP-dependent, Windows terminals are not TCP/IP-dependent. The ICA display protocol supports both TCP/IP networks and IPX/SPX. The display protocol that a thin-client device uses to upload user input to the server and download graphical output to the client can limit the device, but such limitations aren't inherent in the device.

What is consistent about Windows terminals is their Windowscentric design. The local OS that a Windows terminal runs on might not be Windows-based (currently, most Windows terminals use a proprietary OS—not Windows CE, although Windows CE devices such as NCD's ThinSTAR are now on the market), but the operating environment is always NT.