COMP3122 Network Management Richard Henson Worcester Business School March 2011

Week 9 – Thin Clients, Connectivity, Mixed Networks, and Virtualisation Objectives –explain the reasoning behind using different levels for client- based processing –explain the similarities and differences in practical implementations that deliver client-server functionality to the desktop –identify the software and hardware requirements for data one one type of network to be forwarded onto another –explain the process of terminal emulation and how terminal services and other software can deliver this to the desktop –Relate issues of bandwidth to the use of thin clients and terminal services

A matter of Fashion or Functionality? In the very early days of networking, there were no clients… (or even users!) –all computer input via cards and tape –output only to printers When clients (or VDUS) were introduced, early 1970s, they really were “dumb”! –microprocessor only just been invented! –interrupt driven processing hadn’t been implemented

The dawn of the “intelligent client” First “8 bit” processor (Intel 8008) available in 1973… –took two years to develop a motherboard & operating system expected that “users” would write their own apps –1975, the first microcomputer: The Altair scope for “intelligence on the desktop” By 1981, microcomputers popular in the home… –IBM PC was introduced to see whether business would make use of desktop computing…

Success of the Business Micro Businesses used the IBM micro –applications became commercially available –large organisations wanted to exchange data… between desktops between desktop and server Through OSI & IEEE802 standards, the networked PC & LANs became possible: –centralised computers could interface with microcomputers –popular early implementations: –Novell Netware –DEC PCSA

Servers provide Services In the early days, the server (host) was king –user device VDU (Visual Display Unit) or Terminal had no processing ability –everything controlled from the centre Once microcomputers could connect to servers –host-VDU/terminal -> server-client –clients provided richer user experience But, servers retained control –provided client access to resources via services

Clients make services accessible to users… Servers hold secure data… –should be kept well away from users! Users can only access data/resources on a client-server network via a request to a server Depending on the server architecture: –make requests directly via commands inputted from a dumb terminal –make requests from an intelligent client through interprocess communication

Dumb Terminals Strictly speaking, not network devices at all! –no local processing capability Still useful for allowing remote input and output to a computer in a different location –e.g. Bank ATM machines –e.g. Travel Agent on-line booking facilities Advantages: –provide secure authentication to secure systems –work with low bandwidth –fairly robust –no local software, little to go wrong

Limitations of Dumb Terminals Only offer a limited functionality to the desktop user –low resolution screen display –fairly basic user interface Not really clients at all: –can’t be used for client-server applications –can’t support peripheral devices

Levels of Distribution in Client- Server computing Between them, client and server need to handle: –processing –storage –resources –applications –security Client end Server end

The Basic Client Needs software to enable and manage communication with the server –MUST have some processing capability –interprocess communication needs a common client- server communication protocol e.g. TCP/IP First client service request in a user session is likely to be domain logon… –handled by redirector process: client-end requests services server-end either either accepts or rejects service requests

Installation of Domain Clients Much more complex than dumb terminals –(just needed to be plugged in and switched on!) Need to install an operating system and networking software: –EITHER manually using appropriate media containing the necessary software –OR by one of the previously discussed remote methods from a shared distribution folder on a server Final part: –installed client needs to become part of the domain so users can use it to log on –Involves registering with active directory

Where to put Applications? Could be installed on the Server –run remotely like web-based “SaaS” (software-as-a- Service) systems –use local CPU power to run applications Problems: –bandwidth (high – very high if application downloaded) –lot of CPU cycles on the server if many users on SaaS –local availability of dlls, drivers etc. to run the required applications

End-User Computing & FAT Clients Users wanted to do it all from their own desktop Networks often slow… –became standard practice to take distribution even further: install, access, run applications on clients Client machines running applications using their own CPU cycles… –took processing away from the centre: welcome –allowed users to do their own thing: unwelcome! –saved money on expensive, centralised computing: management buy-in Result… –most organisations rapidly put end-ser computing (and FAT clients) into practice

Terminal Emulation All about making a PC or other device behave as if it was a dumb terminal (!) (thin client becomes 2D?) –achieved through software running on client that effectively bypasses the CPU for many processes and sends them to the server Historically, terminal emulation has produced a text-based screen display –low usage of bandwidth Windows-based terminal emulation products available for some time –but.. higher usage of bandwidth to support GUI

Why Use Terminal Emulation? Advantages: –lower TCO makes use of old PCs (even old Pentium I, II) saves money having to upgrade existing machines –screen response very fast –enhanced security (no use of local memory or h/d) –remote server access for administrators –remote client support Disadvantages –extra CPU and memory demands on the server –still use some bandwidth clients running applications locally would use zero bandwidth

Terminal Emulation Options Citrix Metaframe –very popular before Windows released Terminal Server –still an important player… Windows Terminal Server –why bother with something else if the product is already supplied… and works?

Windows Servers & Terminal Server (1) Like Citrix, allows multiuser access to a Server at low bandwidth (e.g. using a standard telephone link) Windows-based applications can run on the server and utilise just a user interface at the client end –low bandwidth because just keystrokes, mouse clicks and mouse movements are communicated Standard interface: users may have different hardware, but the screen display will be the same, no matter what the platform

Windows Servers & Terminal Server (2) Terminal Server –Manages resources at the server end for each client session –Gives each user their unique desktop –Receives and processes all keystrokes and mouse actions –Directs all display output to the appropriate client Terminal Client: –Just displays the desktop and GUI

Windows Servers & Terminal Server (3) A Terminal Services client “session” –opens on the client as a window within the existing local desktop –remote desktop runs within that window –only uses CPU power to connect with the server and display the user interface –strictly speaking a “thin” client, but uses very few local CPU cycles beyond those needed to run the operating system

Windows Servers & Terminal Server (4) Communications Protocol –RDP (Remote Desktop Protocol) –optimised to display graphical elements to the clients –application layer –runs on top of TCP/IP –like Microsoft NetMeeting, based on ITU T120 standard

Low Hardware & OS Requirements of Terminal Services… Windows 2000/XP: –32Mb RAM, Pentium processor Windows 98: –16Mb RAM, 486 Windows 95 (or even 3.1!!) –16Mb RAM, 386 Windows CE –depends on the vendor If non-windows platform –use Citrix metaframe

Client-end Terminal Services Software Versions: –16-bit for Windows-based computers running very old Windows for Workgroups with the 32-bit TCP/IP stack –32-bit Windows-based computers –64-bit with recent Windows (e.g. w2k3 r2)… Client support for: –Windows CE Handheld PC –Windows-based terminals

Applications and Terminal Services 32-bit applications run more efficiently –using legacy 16-bit apps: reduced number of users can be connected increased memory overhead 64-bit systems even more efficient..

Terminal Services (Windows 2003 Enhancements) More users supported per high-end server Windows Management Instrumentation (WMI) provider enhances remote management capabilities "Terminal Services Client“ -> Remote Desktop Connection –RDP 5.1 client features a much improved user interface Remote desktop users can: –save connection settings –easily switch between windowed and full screen mode –dynamically alter their remote experience to match the available bandwidth

Terminal Services & Windows continued Many local resources now available within the remote session, including: –client file system, smart cards, audio (output), serial ports, printers (including network), and the clipboard Allows users to easily take advantage of the capabilities of their client device from within the remote session –e.g. files can be opened, saved and printed to the users local PC, regardless of whether the application is running locally or remotely –improved software restriction policies, roaming profile enhancements, and new application compatibility modes. –colour depth can be selected from 256 colors (8-bit) to True Color (24-bit), and resolution can be set from 640 x 480 up to 1600 x 120

Terminal Servers Preferably member servers, not domain controllers –need plenty of RAM (4-10 Mb required for each user) –recommended installed on an NTFS partition (multisession security for each users “live” data) & use fast, reliable hard disks (pref SCSI, SCSI-2 and RAID) –need a high performance network adapter card

Unix Terminal Emulation Microsoft favours FAT client Unix favours Thin client or terminal emulation –Packages like UWIN: runs via a PC emulates terminal services give features of a traditional Unix operating system on a Windows platform desktop

Virtualisation (Windows 2008 Server, Citrix, VMware, etc.) The use of software to allow a piece of hardware to run multiple operating system images at the same time –Possible to run Windows OS under Mac OS –run multiple versions of Windows OS on the same PC Slightly different from terminal services but getting popular… Enables the creation of a “virtual” (rather than actual) version of any software environment on the desktop, e.g. Operating Systems, a server, a storage device or networks, an application

“The Cloud” Outsourcing on a grand scale… –With connectivity via world wide web “Back to the Future” –Quote from IBM in 1950s: “I think there is a world market for about five computers.” attributed to J. Watson –“The cloud” will behave like just one massive mainframe computer providing all user services –no FAT clients needed… just enough processing at the client end to run a browser could be a very small device could use wireless protocols to connect…

What (physically) is The Cloud Lots of servers connected together in clusters to provided different services Attractive but… –has disadvantages of outsourcing in terms of control –With extra challenge that the user doesn’t know where there data physically is at a particular time… SCARY? Server location also a matter of some concern for legal reasons…

Thanks for listening