THINC: A Virtual Display Architecture for Thin-Client Computing
Ricardo A. Baratto, Leonard N. Kim, Jason Nieh
Network Computing Laboratory
Columbia University

isolation...

Source: Internet Mapping Project (http://research.lumeta.com/ches/map/)

...connectivity

dis-integration of the computer

network
storage

clusters and grid
computing

remote display

display updates

input

benefits

ubiquitous access

remote collaboration

online help

stateless client

application processing

and data

secure server room

thin clients

existing systems

existing performance problem

THINC

virtual display architecture

high performance remote display

transparent operation

system architecture

display protocol

translation

delivery

system architecture

applications

window

system

device

driver

framebuffer

applications

window

system

device

driver

framebuffer

high-level requests

interception and redirection

stateful client hurts mobility

app – window system synchronization

applications

window

system

framebuffer

device

driver

raw pixels

high-level requests

interception and redirection

lose semantics: difficult to encode

virtual display architecture

benefits

benefits

benefits

benefits

display protocol

Inspired by Sun Ray protocol

2D Primitives

copy

solid and tile fill

bitmap fill

raw

Video

two key problems

how do we translate
from application commands
to the display protocol?

how and when do we send display updates?

translation

use and preserve semantic information for efficient translation

use semantic information when doing translation

translation

use request semantics to generate update

req: fill window W, color C

application

window

system

req: fill [x,y,w,h] color C

THINC

update: solid fill

[x,y,w,h] color C

use semantic information when doing translation

preserve semantic information throughout the system

translation

preserving semantics: offscreen rendering

draw

offscreen regions

abcde

copy

abcde

display

offscreen rendering (cont)

offscreen region

command log

merge, clip, and discard commands as needed

using and preserving semantics: video

reuse existing hardware acceleration application interfaces

YUV (luminance-chrominance) color space

format independence

client hardware acceleration (scaling for free)

delivery

maximize interactive response of the system

delivery

transmit updates as soon as possible

merge, clip, and discard updates as needed

shortest remaining size first scheduler

client buffer

C1

C2

C3

...

Cn

real time

.
.
.

queue 1

queue p

cmd
size

beyond remote display

audio

audio

applications

OS

virtual audio
driver

audio
daemon

audio data

audio data

MobiDesk: Mobile Virtual

Desktop Computing

MobiDesk

virtualization

PC

hardware

OS

Net

user session

virtualization + translation

hardware

OS

Net

user session

MobiDesk

virtualization

operating system: zap

network: move

display: thinc

A2M: Access-assured

Mobile Desktop Computing

centralization

DDoS target

computers
out of service

A2M

implementation

X/Linux server

ongoing: windows server

X/Linux, windows, PDA, Java clients

experimental results

web and video performance

comparison to existing systems

Internet 2 sites around the globe

“ ”

LAN

WAN

802.11g

web browsing performance

a/v playback quality

NY

MA

PA

MN

NM

CA

CA

IE

FI

KR

PR

Internet2 web browsing performance

Internet2 a/v playback quality

conclusions

THINC:

virtual display architecture transparently leverages existing display infrastructure

efficient translation by using and preserving semantic information from display request

delivery mechanisms increase responsiveness of the system

for more info...
http://www.ncl.cs.columbia.edu

backup

Web Browsing Data Transfer

A/V Data Transfer

Welcome and thank you for coming. My name is ricardo, and today i will be presenting THINC, a virtual display architecture for thin-client computing. This is work done by leo kim,jason nieh and myself at the network computing laboratory at columbia university.

The advent of network technology has allowed us to move from a world of complete computer isolation ...

to a world of extreme connectivity, where millions of computers and all kinds of devices are interconnected to one another.

furthermore, as network capacity and ubiquity have increased, we have come to witness a phenomenon that has been denominated ...

the dis-integration of the computer. And what i mean by this is our computing environment is no longer confined to the box in front of us, but instead it's all around us, and networks replace what once were internal communication paths in the computer.

two of the most popular examples of this phenomenon are <click> network storage and <click> clusters and grid computing

a third example of the dis-integration of the computer is...

...remote display.

remote display is a client/server architecture that decouples a computer from the devices used to interact with it, such as the monitor, keyboard, and mouse, and uses the network to provide a communication channel between these devices and the computer.

the mode of operation is simple: graphical output from the computer's desktop that would normally be sent to the local video hardware, is instead redirected over the network to a client to be displayed. similarly, in response to the user interacting with the desktop, input events are generated and forwarded from the client back to the server.

given the number of benefits associated with it, it's not surprising the popularity that remote display systems enjoy.

for example, it enables ubiquitous access to our computing session, and all we need is a network connection and a client. and since the required client functionality is so basic, it can be provided almost everywhere, using anything from a simple viewer application to specialized access devices

as the display output is redirected over the network, it can also be replicated and forwarded to multiple clients simultaneously. in this manner, groups of globally distributed users can collaborate by sharing access to a single computer and the applications and instruments on it.

in a similar manner, remote display creates a new paradigm for providing live computer help and technical support. sharing the desktop provides the perfect environment for either showing somebody else how to perform a computer task, or help them troubleshoot a problem.

finally, remote display is the core technology enabling thin clients. A thin client system moves all application processing and data to centralized servers and secure server rooms, and using a remote display protocol provides access to these servers from simple and stateless devices.

the major benefit of the thin-client model is the reduced management costs associated with it. this reduction comes from the fact that the edges of the network, where management is more costly, are composed of simple devices that require little or no maintenance.

remote display has been around for some time now and as a result a number of remote display systems exist today. among the most popular are ...

however, the remote display world as it stands today is suffering from a fundamental performance problem <click>

This graph shows the results of displaying a video clip on the most popular remote display systems, and measuring the playback quality as perceived by the client.

As you can see, none of the systems is able to provide performance that is even close to that of today's desktop computer.

In this context we introduce THINC, a virtual display architecture for high performance remote display..

I'm going to divide the description of THINC in 4 parts

now, to frame the discussion of the system architecture, i'm first going to describe what the traditional display pipeline looks like.

as shown in this figure, graph apps sit at the top and use the window system to

Given this display pipeline, the first question we must answer is where do we intercept display requests?

the first option is to intercept high-level requests between the applications and the window system , and approach used by X and X-based proxies such as NX. In this model, everything below the window system is executed on the client. Intercepting at this level has the advantage of given the rd system complete knowledge and control over the system. unfortunately it all has two serious drawbacks. first, since the window system is at the client, ...

second, since an application's logic and its user interface are typically tightly coupled, running the ui on the client and the logic in the client may result in a need for continuous synchronization over the network. In high-latency wide are network environments this kind of synchronization results in substantial performance degradation.

at the other end of the

in order to maximize the responsiveness of the system, the server transmits updates to the client as soon as possible, by pushing them on the network. this approach guarantees minimum delay plus it doesn't suffer as much as network latency increases

to properly adapt to varying network conditions and slow responding clients, coalesce + discard old updates

srsf analogous to srpt

srpt optimal for minimizing mean response time

as updates are generated, sort them in queues.

the queues are flushed in increasing size

additional real time queue allows us to prioritize updates that provide feedback to user (e.g. cursor change)

now, to frame the discussion of the system architecture, i'm first going to describe what the traditional display pipeline looks like.

now, to frame the discussion of the system architecture, i'm first going to describe what the traditional display pipeline looks like.

now, to frame the discussion of the system architecture, i'm first going to describe what the traditional display pipeline looks like.

mobile virtual desktop computing

desktop hosting architecture. similar to today asp.

server farm where desktop sessions are hosted, with shared storage

proxy-server provides entrance from outside world and hides all details of what is going inside infrastructure.

stateless access devices.

how does it work?

virtualization approach. typical computer looks like this. and for mobidesk what we do is this... <next slide>

introduce a virtualization and translation layer between the session and the underlying computer.

decouples the session from any operating system and hardware instance.

provide: virtual private namespace for each desktop session

sessions can coexist within a single computer

sessions can be migrated across computers

now, to frame the discussion of the system architecture, i'm first going to describe what the traditional display pipeline looks like.

2005-06-13T15:47:06