Citation
Virtual thin client

Material Information

Title:
Virtual thin client : a scalable servicediscovery approach for pervasive computing
Creator:
Coons, Samuel W., 1961- ( Dissertant )
Helal, Abdelsalam A. ( Thesis advisor )
Chow, Randy Y. ( Reviewer )
Wong, Tan ( Reviewer )
Place of Publication:
Gainesville, Fla.
Publisher:
University of Florida
Publication Date:
Copyright Date:
2001
Language:
English
Physical Description:
xi, 68 p. ; ill.

Subjects

Subjects / Keywords:
Computer technology ( jstor )
Java ( jstor )
Mobile devices ( jstor )
Operating systems ( jstor )
Pixels ( jstor )
Rectangles ( jstor )
Software ( jstor )
Ubiquitous computing ( jstor )
Viewers ( jstor )
Windows ( jstor )
Client/server computing ( lcsh )
Computer and Information Science and Engineering thesis, M.E ( lcsh )
Dissertations, Academic -- Computer and Information Science and Engineering -- UF ( lcsh )
Network computers ( lcsh )
Wireless communication systems ( lcsh )
Genre:
government publication (state, provincial, terriorial, dependent) ( marcgt )
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )

Notes

Abstract:
Thin client technology is widely available for many platforms as an alternative configuration to traditional network architectures. This research closely examines the design of thin client technology and how it could be used in a mobile computing environment. This examination is placed in the context of rapidly evolving technologies such as Sun Microsystem's Kilobyte Virtual Machine implementation for mobile devices. A survey of differing classes of mobile devices shows the potential for expanding these devices' capability beyond locally installed programs. Wireless connectivity is allowing developers to plan on high-bandwidth connectivity for networked applications though this is still in its infancy. A combination of these synergistic technologies could potentially create a new type of computing environment. This new environment is consistent with the pervasive computing paradigm created in the early 1990s. This research project outlines the capabilities that this type of environment could create and implements a subset of this vision using thin client technology in combination with a Java 2 Micro Edition enabled, mobile device. The goal is to fully understand the capabilities and limitations of such a device within the design and testing environment created. ( , )
Subject:
J2ME, thin client, mobile computing
Thesis:
Thesis (M.E.)--University of Florida, 2001.
Bibliography:
Includes bibliographical references (p. 66-67).
General Note:
Title from first page of PDF file.
General Note:
Document formatted into pages; contains xi, 68 p.; also contains graphics.
General Note:
Vita.
Statement of Responsibility:
by Samuel W. Coons III.

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
48515006 ( OCLC )
002766277 ( AlephBibNum )
ANP4316 ( NOTIS )

Downloads

This item has the following downloads:


Full Text











VIRTUAL THIN CLIENT:
A SCALABLE SERVICE DISCOVERY APPROACH FOR PERVASIVE
COMPUTING

















By

SAMUEL W. COONS III


A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF ENGINEERING

UNIVERSITY OF FLORIDA


2001




























Copyright 2001

by

Samuel W. Coons III



























To my Lovely Family















ACKNOWLEDGMENTS

I would like to express my sincere thanks to Dr. Sumi Helal for his guidance and

support in completion of this thesis. His vision and expertise were invaluable assets for

which I am truly grateful. I would also like to thank Dr. Randy Chow and Dr. Tan Wong

for their support in serving on my supervisory committee.

This research was sponsored in part by the Motorola JinIDEN project. I am

extremely thankful for participating in the research. The discussions of that group,

including David Nordstedt and Choonhwa Lee, were of great value in helping to develop

the directions of this research.

This would not have been possible without the loving support of my wife, Jamie

and my two sons, Sam and Chandler. I thank them for their patience, love and support

during the past 2 years.
















TABLE OF CONTENTS

page

A C K N O W L E D G M E N T S ................................................................................................. iv

LIST OF TABLES ............. .............. ...... ........ ... ................. vii

LIST OF FIGURES ................................. .. .. ................. .......... viii

A B STR A C T ................. .......................................................................................... x

INTRODUCTION .................................. .. ... .... .......................

Introduction to Thin-Client Technology ................................... ................... ............. 1
C lient S erv er A rch itectu re .......................................................................................... 1
T h in C lien ts ...................................... .................................... .............. 2
A d v an tag e s ....................................................................... 4
Disadvantages ........................................ 4
T hin C lient T echnologies....................................................... ......................... 5
Network Computer (NC) ................... ................ .................. 5
Citrix Independent Computing Architecture (ICA) ............................................ 8
Virtual Network Computing (VNC) ............................. ..... ...................... 9
Em ergence of M obile D evices..................................................... ......................... 15
M obile Com m unications ............................................................ ......... ...... 16
Personal D igital A assistant (PD A ) ........................................ ........................ 16
Personal Com m unication Services (PC S)............................................. .. .................. 17
M obile D evice O operating System s ........................................ ........ .............. 20
E enabling T echnologies......................................................... ............ ...... ...... 22
Java 2 M icro E edition (J2M E ) ......................................................................... ... 22
J in i ....................................................................................... 2 6

PERVASIVE COMPUTING AND MOBILE DEVICES .............................................33

D efin ition s ..................................................... 3 3
D e fic ie n c ie s................. .. ................................................ ........................ ......... 3 5
Convergence of N ew Technologies ................................................................ ........ 36

VIRTUAL THIN CLIENT APPROACH ................................... .....................................37

Problem........................ ................... 37
U n iq u en e ss ........................................................................................ 3 8


v









A architectural V ision.................... .............. .................... .. .. ...... ..... .. ............ 38
Design Requirements ........................................... .............. .. 39
L im itatio n s .............................................................................. 4 0

IM PL E M E N T A T IO N ............................................................................. ......................4 1

T technical Sum m ary .................................................................. .. .......... ... 4 1
C lie n t ................... ................... ...................4.........1
C lass M apping ........................................ 42
F low of C control ..................................................................... 4 3
VtcViewer .......................... .............. 43
V tc C a n v a s ................................ ......... .. ................................................ 4 4
Event M anagem ent ........................................ 46

TE ST A N D E V A L U A T IO N ........................................................................................ 50

Testing Environm ent ............... ............................... ........ ..... ............. 51
Goals of Experim ents .............................................. ..................... 51
Experiment I..................................................... ........ 52
Initial screen rendering........................................................ 52
C onclu sion ........................................ 55
Experiment II .......................... ........... ..........................55
Data throughput....................................... .............. 55
C onclu sion ........................................ 57
Experim ent III ................ ....... ....... ................ ........ .................... 57
Complexity of input .............................................. 57
C onclu sion ........................................ 60
Experim ent IV ......... ...... ............. ................ ........ ....... .............. 61
Dynamic pipeline measurement ................... ................. .................. 61
C onclu sion ........................................ 63
C o n c lu sio n s ............. ......... .. .............. .. ....................................................... 6 3

R E F E R E N C E S ................................................................66

BIOGRAPHICAL SKETCH ...................... ..................... .. .............................68
















LIST OF TABLES



Table Page

1-1. Minimum hardware requirements for Network Computer [4] ....................................6

1-2. Characteristics of Cellular and Cordless low-tier PCS Technologies [10]..................19

4-1. Class summary of the javax.microedition.lcdui package ...........................................42

5-1. Em ulator host environm ent......................................... .................. ............... 51

5-2. Com prison of V TC throughput......................................................... ............... 57

5-3. Statistics for "fast" sim ulation .................................... ......... ............................... 59

5-4. Statistics for "slow sim ulation .............................................................................. 60
















LIST OF FIGURES



Figure Page

1-1. Thin-Client C onceptual V iew ............................................... ............................ 2

1-2 T h in C lient P ro ce ss........................................................................................ .....4

1-3. Comparison of NC Reference and NetPC ....................................... ............... 7

1-4. An X desktop viewed from Microsoft Internet Explorer on a PC ............. ..............11

1-5. A Windows machined viewed from a native X viewer ..............................................11

1-6. Palm IIIc H andheld com puter .............................................. ............................. 16

1-7. Basic PCS N etw ork Architecture ........................................................................... 18

1-8. U pgrading 2G System s to 3G .............................................. ............................. 20

1-9. J2M E softw are layer stack ................................................. ............................... 23

1-10. Relationship between J2ME configurations and J2SE .............................................25

1-11. High Level Architectural View MIDP Device ................................ .................27

3-1. Virtual Thin Client Global Architecture................................... ......................... 39

4-1. Start up screen for the V T C ........................................ .............................................44

4-2. Flow chart for the main processing loop thread ................................. ................ 45

4-3. State Diagram for key event management for the VTC ..........................................47

5-1 Conceptual view of VTC performance pipeline ...... .................................... 50

5-2. Initial screen rendering test program ............................................ ..... ................. 53

5-3. Initial R entering Tim e R results ............................................. ............................. 53

5-4. Initial R entering Tim e (802.11)......................................................... ............... 54









5-5. Counter application for throughput measurement .................................. ...............56

5-6. C om m V iew w window .................................................................... ....... .....................56

5-7. Frequency chart for event generation time (fast) ............. ..........................................59

5-8. Frequency chart for event generation time (slow) ...................................................60

5-9. Average render tim e for "jum p" events ........................................ ...... ............... 62

5-10. Average aggregate network delay ........................................ .......................... 62

5-11. Server rendering tim e ......................................................................... ................... 63









































ix















Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Engineering

VIRTUAL THIN CLIENT:
A SCALABLE SERVICE DISCOVERY APPROACH FOR PERVASIVE COMPUTING

By

Samuel W. Coons III

August 2001

Chairman: Dr. Abdelsalam Helal
Major Department: Computer Information Science and Engineering

Thin client technology is widely available for many platforms as an alternative

configuration to traditional network architectures. This research closely examines the

design of thin client technology and how it could be used in a mobile computing

environment. This exami nation is placed in the context of rapidly evolving technologies

such as Sun Microsystem's Kilobyte Virtual Machine implementation for mobile devices.

A survey of differing classes of mobile devices shows the potential for expanding these

device's capability beyond locally installed programs. Wireless connectivity is allowing

developers to plan on high-bandwidth connectivity for networked applications though

this is still in its infancy.

A combination of these synergistic technologies could potentially create a new

type of computing environment. This new environment is consistent with the pervasive

computing paradigm created in the early 1990s. This research project outlines the

capabilities that this type of environment could create and implements a subset of this









vision using thin client technology in combination with a Java 2 Micro Edition enabled,

mobile device. The goal is to fully understand the capabilities and limitations of such a

device within the design and testing environment created.














CHAPTER 1
INTRODUCTION

Introduction to Thin-Client Technology

The increasing sophistication of software applications and hardware have created

attraction for the Thin-Client technology. Its use has become widespread within the

traditional desktop computing environment and is rapidly moving into the mobile

domain.

The thin client architecture was developed to ease the burden of rapid

obsolescence of hardware and software. Thin clients also give network administrators

great flexibility in managing, upgrading and maintaining software made available to its

users. This begs the question of what is a thin client? The foundation of thin clients is in

traditional client server architectures.

Client Server Architecture

Client Server is an architecture that defines a network in terms of the hardware

and software resources that are available. The server is typically a computer with

considerable resources such as a large amount of RAM and a large, very fast hard drive.

The server is the component that manages the infrastructure for the clients to participate

in the network. Synchronization, security, and resource management are some of the

responsibilities of the server. The server must provide an environment where all clients

have access to the appropriate resources of the network. The server is equipped to

provide these services using software specifically designed to run and manage a network.

It provides additional services such as internet access, file storage, and printers.









The client, therefore, is any other participating member of the network. The client

may be machines as fully capable as the server that perform none of the server's duties.

The client connects to the network via some means of a wired connection (Ethernet,

Coaxial, etc). Wireless modes of connection gaining popularity include the IEEE 802.11

standard. This general network configuration is what defines the client server

architecture. The server provides services and the client is a consumer of those services.

Thin Clients

The notion of "thin" clients was developed as an alternative to the rapidly

changing hardware and software landscape. It was postulated that if devices could use

existing user interfaces, then perhaps the computational workload could be offloaded to a

"fat" entity. This is shown in Figure 1-1. This entity is typically a powerful server that

can serve many clients each referred to as a session. The client does not own much in

terms of local resources but it still has the appearance of running large applications that

require fast processors and a great deal of RAM.


Figure 1-1. Thin-Client Conceptual View [2]


Client









The thin client architecture is somewhat of a return to the mainframe paradigm

[1]. The applications are resident on the server and the client must access the server to

execute them. The application domain, though, has changed significantly over the past

20 years which has fueled the need for more powerful clients. The desktop personal

computer market was a direct result of the failure of large mainframes to satisfy the

emerging, small business application market. This phenomenon combined with a

spiraling decrease in costs and exponential increase in capability created the modem

computing age as we know it. These new, capable desktop machines were soon

networked together which gave rise to two observations [1]:

Rapid change in either software or hardware is an administrative problem.
Client resources are often wasted.

One solution to these problems was to implement thin clients. There are three

main components to any thin client architecture: the server, the client, and the protocol.

The server represents the computational workhorse of the system. Typically, the server

operating system supports multiple users. The technical premise behind thin clients is the

establishment of a virtual channel between the client and the server. The channel is used

to pass data between the client and server. The client sends event data such as

keystrokes and pointer movements. The server receives the event data, interprets its

meaning within the context of the current environment and calculates a new display.

These display data are then packaged in the protocol and sent back to the client to

generate an updated display to the user. This process is captured in Figure 1-2.

It is worthwhile to note that the updated display is rendered using resources that

the client must supply. The client normally dedicates most of its resources to producing










this display [1]. Various protocols and methods for encoding the display data are

discussed in a later section.


Figure 1-2. Thin Client Process.



Advantages

Some of the advantages of thin client architectures have already been mentioned.

One clear advantage is that classes of devices may not have an alternative if they want to

access the powerful applications available to the desktop market. Many mobile devices

are constrained by the processor and memory limitations inherent to their form factor.

This does not preclude their participation in the network, though, if a suitable interface

and network connection are available.

Disadvantages

The disadvantages of using thin client technology stem from its reliance on the

network for its functionality. If problems arise from the network side, then any thin


user logs on for new session
I


events are passed to server


updated display sent to client


It


L









client is affected in some manner. The main requirement is that the client must operate in

a connected state. This may pose challenges to mobile devices that periodically lose

connectivity due to external conditions such as loss or degradation of the RF signal. The

power constraints of mobile devices may also cause a loss of network connectivity.

There may be issues with scalability. As the number of clients increases, the

demand placed on the server increases proportionally. The number of clients may not

translate directly into CPU operations, but each session does require address space and

memory from the server. Virtual memory addresses could become critical if the number

of users becomes large enough [1]. The operating system may not support the required

number of addresses if it is a multi-user system and each user is using applications that

require a significant amount of virtual memory. This problem is being addressed with the

release of newer operating systems that support a large number of virtual addresses such

as Windows 2000.

The last element to examine is the opportunity cost of not purchasing a more

capable machine. It is reasonable to examine the alternatives to using a thin client. If

there is a need for local computing power, then a thin client solution may not be the best

alternative.

Thin Client Technologies

Various thin client technologies are available today. This brief survey frames the

next three surveys with its characteristics, strengths and weaknesses.

Network Computer (NC)

The network computer concept originated at the Oracle Corporation. A

consortium formed between several major vendors including Apple, IBM, Oracle, and

Sun. The consortium soon fragmented with many vendors developing a proprietary









product. Oracle no longer promotes the idea of a network computer but it is still

available in today's market. It is worthwhile to examine the network computer as this

concept still forms the basis for many "semi" thin client architectures.

The genesis of the NC arose from the fact that at the time of its conception in

1995, there was a price difference of approximately $500 between desktop PCs and the

proposed NC [3]. This was a significant difference at the time because the sub $1000 PC

was not a reality. An NC serves the role of a client and does not possess the capability to

act as a server. The NC must have a network connection to function and therefore is not

a standalone computer. There is both a hardware and software component to the concept.

The hardware configuration for an NC is different from both the PC and the

mainframe dumb terminal. The NC could, and does in some cases, possess a CPU

comparable to that of a PC. It does not contain any permanent storage, though, which is

similar to the dumb terminal. The Oracle reference profile was created to standardize the

device so manufacturers could easily develop products that were compatible. Table 1-1

lists the minimum hardware required for an NC.




Table 1-1. Minimum hardware requirements for Network Computer [4]
Hardware Minimum Requirement
Video VGA, 640 x 480 output

Pointing device Mouse or compatible pointing device

Text input Keyboard or comparable input device

Audio Audio board or sound capable motherboard

Hard drive NO persistent storage required










The hardware specification was intended to be as open as possible to allow a wide

range of vendors to participate in its market share. The underlying operating system and

the hardware itself are not specified. As the NC consortium split apart, many vendors

chose to implement their own solutions as evident in Figure 1-3. Microsoft, with its

NetPC, chose to specify proprietary products for many of the open standards.


NCRef NetPC

lets Other Appl Java Applets Windows

browser GUI Microsoft Desktop
Appl.
N JVM MS JVM

JavaOS I
i; dA QO


Intel Pentium HW


Non Specific HW


Figure 1-3. Comparison of NC Reference and NetPC [5]



The software side of the network computer was intended to support a wide range

of protocols all based on existing standards at that time. The following IP based

protocols were specified:

* TCP- Transmission Control Protocol
* FTP- File Transfer Protocol
* Telnet- character based terminal emulation
* NFS- Network File System
* UDP- User Datagram Protocol
* SNMP- Simple Network Management Protocol
* DHCP- Dynamic Host Configuration Protocol
* BOOTP- Boot Protocol









There are various other standards specified including WWW, mail protocols and

multi-media formats. The Java programming language forms the basis for the operations

performed by the NC. The NC utilizes Java applets to execute code within the browser

loaded on the NC. Java's platform independence give it great flexibility in using

heterogeneous hardware together in a single network. The Java virtual machine that is

provided with the browser then executes the applet. This is a variation on the truly "thin"

client as there must be some processing capability available locally.

Citrix Independent Computing Architecture (ICA)

Citrix ICA is a thin client architecture that has its roots in the X-Window

standard. In contrast to the NC just examined, X-Window was developed to provide

cross platform connectivity to software running on a Unix server. The X Window is

comprised of a layer of software that resides between the server's operating system and

the applications that are running. This design allowed X Window clients access to the

server's application layer via the X Window layer. The server's X Window layer acted

as a buffer for the client so that no direct interaction was necessary with the server's

operating system [3].

The Citrix ICA family of products is a variation of the X Window model. Citrix

first developed its product for Microsoft that allowed Windows NT users that ability to

access Windows programs from a client that did not support any Windows programming.

In essence, the Citrix ICA is an X Window version for Microsoft Windows applications.

The basic client requirements for utilizing ICA include 640 kb of RAM, Intell 286

processor or equivalent, keyboard and display. This is the minimum requirements

necessary in the traditional desktop arena and is much less restrictive than most









alternatives. The bandwidth requirements average in the 20 kbps range which is suitable

for most modems faster than 14.4 kbps [6].

Additional features include:

* Works with any Windows program
* Delivers Windows programs to non-Windows platforms
* Built into the latest versions of Windows (Windows NT 4.0 Terminal Server and
Windows 2000)
* Can coexist with network computers
* Network protocol independent (most run on TCP/IP)

It is a clear advantage that Microsoft has accepted the ICA protocol as its standard

for server side computing. The source code is not publicly available which makes

modifications difficult at best. However, the Virtual Channel SDK allows value added

resellers to make customized changes. This information is available on the Citrix

website. It is also unclear at this time if ICA will dominate this market as previous

Microsoft operating systems [3].

The possible disadvantages of using this technology is that end users must have

needed Windows applications loaded onto the server vice locally. This prevents users

from loading software that might be needed expeditiously or on a customized basis. This

is a fundamental control issue and may be a positive for configuration management but

does limit the flexibility of the user [3].

Virtual Network Computing (VNC)

VNC is a thin client product that was developed at AT&T Laboratories in

Cambridge, England. This system is in effect a remote display system that allows you to

view a computing desktop environment from virtually anywhere via any device. VNC is

based on a simple display protocol that is platform independent. It can even be used via a









web browser so that an end user may not even need to bring a mobile device if there is

access to the internet.

The origin of VNC is similar to many thin clients. The developers of VNC used

X Window before VNC's development. Several limitations of X Window were observed

that severely restricted its use in some cases [7].

* X Window required the client to run an X server program. A burden on many
resource constrained devices.
* Security within the X server was to lenient
* High latency links were problematically slow for application startups


The first attempt at a creating a more responsive solution resulted in Videotile.

The Videotile was a device designed to receive raw video that was created from a remote

computer. The drawback to this approach was its large amount of bandwidth consumed.

The Videotile concept evolved with the release of the Java language. A browser utilizing

Java was created for the client and this class file was only 6 kilobytes [7]! The following

screenshots are representative of the wide range of devices with which VNC is

compatible.

VNC Protocol

At the heart of VNC is its protocol. The protocol is designed to create

framebuffers that can be rendered in any operating system. The client side must only be

capable of rendering pixel data to its display. Its power and versatility lie in the

simplicity of the protocol. As with any thin client, all that is needed is a reliable transport

mechanism [7].

The VNC protocol is named RFB for Remote Frame Buffer. The RFB consists of

header information describing the message type and data. The data is used to render the















-=711 j


-j~


..................................

... ..........................................


Done


An X desktop viewed from Microsoft Internet


Explorer on a PC [8]


I i


Figure 1-5. A Windows machined viewed from a native X viewer [8]


Figure 1-4.


' I- I: I F~h i, ,I:,
III IT,


II :,1 I, : n


Hi iI xle

inhimll xlen m









display on the server side. The client (or more commonly called the viewer) interprets

the input as pixel data. This pixel data is bundled as a rectangle of display and passed via

an agreed upon encoding scheme. As parts of the display or rectangles change, they are

compiled into a frame buffer. This frame buffer is sent to the client as an update. The

client does not preserve any state information which makes the device truly "thin". If

connectivity is lost, the device can re-establish a connection at a later time and the

interface will not have changed. The protocol is established in two stages. The first is

the handshaking stage in which the viewer and server agree on several issues. These

issues include the protocol version, any authentication and the initialization of both the

server and the viewer. This is followed by the passing of display data for the rest of the

session.

The viewer and server will negotiate the encoding scheme and format. The

encoding scheme refers to the method of representing a rectangle of pixel data. The base

method that must be supported by all servers is the representation of raw pixels. This

method is named raw encoding. Raw encoding sends n values of pixel data where n

equals the total number of pixels in a w (width) by / (length) rectangle. The pixels are

updated in left to right scanline order. This requires that the rectangle be redrawn by the

viewer which can be expensive in terms of both processor time and network bandwidth

[23].

The other primary encoding schemes include the Rise and Run length (RRE)

encoding scheme. The RRE idea is to partition the data into rectangles of rectangles.

This essentially subdivides a rectangle into regions of single pixel values that can be

more efficiently sent over the network. Any given set of rectangles can be reconstituted









to create the original rectangle of data. The actual encoding consists of a background

pixel followed by N sub rectangles where each sub rectangle has an associated x,y

coordinate and a width and a height value [23].

The Copy RRE (CoRRE) encoding method is an offshoot of the RRE method.

The main difference is that the largest possible rectangle that may be sent is 255 by 255

pixels. It has been shown that results in better compression for typical desktops. The

rectangles that typically do not encode well are those such as images and these must be

sent as raw encoding. This gives the server flexibility in deciding how each sub rectangle

should be encoded. The RRE method is an all-or-nothing encoding scheme [23].

The Hextile encoding scheme is a variation on the CoRRE. The main difference

is that the rectangles are broken into 16 by 16 tiles. This allows for the dimension data to

be efficiently sent as 16 bit values with each dimension represented by 4 bits. This

scheme also includes background pixel values. Each tile is colored by using the raw

method or a variation of RRE.

Messages

The initial message, ProtocolVersion, is sent from the server to the client. This

12-byte message details the protocol version that is supported by the server. The client

then sends a like message in return except that the server must respect the clients wishes

to use the requested protocol.

The client and server then agree to an authentication scheme to be used. This

exchange is encapsulated in a 4-byte message. There will not be any use of encryption or

authentication in this version of the VTC.









The client then sends a ClientIntialization message. This is a 1-byte message that

flags the server as available to be shared or not.

The server then replies with a ServerInitialization message. This message is 24

bytes in length and specifies the frame buffer width and height, the server pixel format

and name information. The client may respond with a SetPixelFormat message if it

cannot accept the formatting provided by the server.

VNC Server

The VNC server has been implemented in many languages, including C and Java,

as well as for varying operating systems. The source code in freely available and may be

modified by those interested in doing so. Input events have been modified to suit many

mobile devices such as pens and touch screens. It is for these reasons that the best

candidate to support the Virtual Thin Client is VNC.

Client-Server Interaction

The VNC protocol is, to a large degree, client driven. The client viewer requests

display updates from the server. The request comes in the form of a messages generated

by the viewer. The MIDP event manager for handling low-level events is part of the

Canvas class with javax.microedition.lcdui. Game actions, key events and pointer events

are all part of the Canvas class. The Canvas class also registers a listener to detect these

events. Once the listener detects an event, a message is generated to the server.

The FramebufferUpdateRequest is sent by the viewer to the server. This 10-byte

message specifies the rectangle size and location that the viewer is interested in updating.

The server may respond with a FramebufferUpdate but is not required to do so. One area

of optimization may occur by regulating the number of requests that is sent to the server









by the viewer. KeyEvent messages are 8 bytes and sent in response to a key being

pressed or released. Key type IDs correspond to ASCII representation. PointerEvent

messages are 6 bytes. They are sent in response to movement, press or release of the

pointer device [23].

The FramebufferUpdate message determines what will be redrawn be the viewer.

The message header contains the number of rectangles, the x and y coordinates, the width

and height and the encoding type. The header is followed by a variable number of bytes

that describe the pixels for each rectangle.

It is worthwhile to note that the original intent of the VNC system was to provide

Thin-Client architecture for various windowing operating systems such as Windows NT,

Windows 95/98, X11. This is not a requirement, though, and numerous servers have

been written that do not mirror any windowing system. This is important since the MIDP

does not support any windowing features due to the absence of the AWT package. The

VTC server will be the component that is responsible for ensuring that the appropriate

messages and encoding are handled the way that is acceptable to the viewer. In our

simplified VTC prototype, a minimum number of messages will be supported to ensure

that the MID device participates in the JINI network.


Emergence of Mobile Devices

The use of mobile devices has increased dramatically over the past decade.

Increasingly, computing devices are required outside of traditional, office environments.

These situations require the device to provide functionality where power and

communication may be a scarce commodity. The internet has, collectively, provided

some means of global connectivity but a user must still provide his/her own access. This









access has been satisfied by the wide range of mobile devices. A mobile device can be

defined as any form of computing entity that can function in a variety of environments.

Mobile Communications

Devices can be categorized many ways but there are two genres of devices that

are becoming increasingly popular in this market segment, Personal Digital Assistants

(PDA) and Personal Communication Services (PCS) devices.

Personal Digital Assistant (PDA)

PDAs can be loosely categorized as a class of computing devices that are defined

by their form factor. They roughly fit in the palm of a hand are often referred to as

"palm computers." Figure 1-6 is a picture of a PalmIIIc TM device in its synchronizing

cradle.





















Figure 1-6. Palm IIIc Handheld computer [ 20]



The "palm" reference grew out of the popularity of the PalmPilot device which

has captured a large share of the PDA market. PDA's have limited RAM in the 2-32









Mbytes range, small display which may or may not support color, and typically use a

touch screen in combination with a stylus for user input. The functionality of PDAs

varies greatly from simple contact management to word processing and internet

connectivity.

PDAs enjoyed record sales for the year 2000. Sales of PDAs grew from 5.1

million in 1999 to 9.4 million in 2000. It is estimated by the Gartner Group that PDA

sales will be in the 30 million unit range by the year 2004. Major vendors for this type of

product include Palm, Compaq, Handspring, Hewlet Packard and others. There are broad

targets for manufacturers to capture with a particular device. Handspring, for example, is

concentrating on producing devices that have a large selection on expandable features.

These features come as plug in modules for the proprietary expansion slot named

Springboard. These modules will allow users to use, among others, Global Position

Satellites (GPS), MP3 players, and camera add-ons [9].

Personal Communication Services (PCS)

PCS refers to a wide variety of wireless access and personal mobility services

provided through a small terminal. These services aim to support a communication link

at ay time, place or form [10]. This industry has also experienced dynamic growth in the

last decade and several technologies has been introduced as a result. The most common

thread in all PCS systems is a connection to a Public Switched Telephone Network

(PSTN). The most recent generation systems have expanded to include not only voice,

but wideband data services as well [10]. This has allowed internet and multimedia

applications to become increasingly popular. Figure 1-7 illustrates the basic PCS

architecture.











Wireline Transport Network


Figure 1-7. Basic PCS Network Architecture [10]



Mobile users carry some type of communication device referred to as a mobile

station. The mobile station communicates with the base station directly. Different types

of mobile stations have varying degrees power output and ranges. The radio coverage of

a base station is called a cell. Some systems have controllers for the base stations known

as base station controllers. The base stations use either a land line or dedicated

microwave connection to reach the wireline transport network [10].

The wireline transport network consists of a mobile switching center and the links

to the base stations. These centers are highly specialized switches produced for mobile

applications [10].

Current PCS systems can be broadly characterized into high-tier digital systems

for wide-ranging services, low-tier systems for standard business and residential use, and









cordless access [10]. Examples of high-tier systems include Global System for Mobile

Communication (GSM), IS-95 CDMA-based cdmaOne System, and Personal Digital

Cellular (PDC). Table 1-2 describes the general characteristics of these systems.


Table 1-2. Characteristics of Cellular and


Cordless low-tier PCS


Technologies [10]


System High-Tier Cellular Low-Tier PCS Cordless

Cell size Large (.4-22 miles) Medium (30-300 ft) Small (30-60 ft)

User speed High (< 160 mph) Medium (< 60 mph) Low (< 30 mph)

Coverage area Large/continuous Medium/ macro and Small/ zonal
macrocells picocells picocells
Handset complexity High Low Low

Handset power High (100-800 mW) Low (5-10 mW) Low (5-10 mW)
consumption
Speech coding rate Low (8-13 Kbps) High (32 Kbps) High (32 Kbps)

Delay or latency High (< 600 ms) Low (< 10 ms) Low (< 20 ms)



It is generally agreed that the PCS wireless technology has evolved for three

generations. The first two having been deployed for voice and very low data rate

services. The limitations on services are due to the specified, vertical architectures of

these systems [10]. Third generation systems, often referred to as 3G, offer the promise

of greater user capacity, higher bandwidth for a number of data applications. The ability

to combine voice transmission with high bandwidth data transmission is viewed by many

as the crown jewel of mobile computing. The first 3G system is scheduled to begin

service in March 2001 in Japan [11]. Figure 1-8 shows a general migration path of

second generation PCS services to 3G and the services that each generation provides.






































Figure 1-8. Upgrading 2G Systems to 3G [11]




The 3G services are important to the future success of many mobile applications.

The ability to use both voice and high bandwidth data services in one device is the goal

of this technology. The 3G is a foundation for creating a truly pervasive computing

environment for mobile users.

Mobile Device Operating Systems

The mobile devices that are in production today still require economic design and

implementation due to the limited form factor. This is true of the system software as well

as the hardware. The operating systems in use for PDAs and PCS devices are tailored for

precise use of the device's memory, processor and user interface. The two prevalent

PDA operating systems are Microsoft's PocketPC and the PalmOS from Palm, Inc.


Broadband data
Video
Fast Internet
Remote access


Enhance voice
European roaming
International roaming
Some data









PocketPC was introduced by Microsoft in April 2000 and is the latest generation

of operating systems for palm personal computers or palm pc. This palm is not to be

confused with the company with the same name. PocketPC evolved from the

WindowsCE operating system which was an earlier attempt at producing a small,

compact operating system for mobile devices. WindowsCE did not have as much

commercial success because of its size and hardware requirements. The PocketPC is a

trimmed-down version of WindowsCE but still runs the basic WindowsCE operating

system. The basic configuration for most of these devices is 16 Mb of RAM (many use

32 Mb), 16 Mb of ROM (the OS uses much of this), and a Hitachi SH3 or NEC MIPS

RISC processor that runs at 70 MHz or better [12]. One key advantage is that PocketPC

supports a Universal Serial Bus (USB) connection for fast synchronization with a desktop

[12].

The PalmOS was first released in 1996 with the introduction of the first Palm

computing device named the Pilot 1000. The PalmPilot line of devices was initially

created to provide a basic set of functional programs to help manage contact information

and a personal calendar. The Palm OS was designed to be compact and fit into a

handheld device. Input was limited to a touch screen and a few buttons but there was no

full handwriting recognition or keyboard [13]. The PalmOS has a unix flavor and its

applications are written in C. It gained immediate support within the development

community and now has a wide range of third party software available. The primary

design goals were to create an inexpensive device small enough for a shirt pocket and

that integrates with a desktop computer. Palm has been very successful at filling this

niche though new devices are rapidly entering the market.









Other operating systems exist for the mobile device market. In particular are those

that must serve the wireless device market or sometimes referred to as wireless

information devices (WID). One of these systems is the EPOC operating system from

Symbian, Inc. Symbian created EPOC specifically for WIDs with the anticipation that

these devices would function in many modes of connectivity and for a wide range of

applications. This is similar to the smart phone and communicator concept. The EPOC

has been split into the operating system engine and GUI components [13]. This allowed

compatibility among applications across a wide range of platforms. The EPOC has

allowed developers to use a consistent API regardless of what network stack may be

plugged in at that time. The EPOC system supports most open development standards

including a Sun approved Java Virtual machine, TCP/IP, Bluetooth, and Wireless

Application Protocol (WAP) among others.

Enabling Technologies

The availability of more capable, mobile devices has challenged the network and

application community to build environments where the devices can operate at their

potential. Two technologies that have emerged from the Java community are the Java 2

Micro Edition (J2ME) and Jini. The J2ME has given the application community a toolset

to build and deploy sophisticated applications for mobile devices. Jini is a network

centric technology that has been evolving for several years. These Java technologies are

explored in greater detail.

Java 2 Micro Edition (J2ME)

In June 1999, Sun Microsystems announced a new version of the Java 2 platform

entitled Java 2 Micro Edition. This version of the Java language was targeted for the

small, resource-constrained computing devices that were rapidly entering the market.









The J2ME entailed developing a new Java virtual machine as well. The first production

release for J2ME would take close to a year to complete as the new virtual machine

required a great deal of work [14].

The design targets for J2ME were basically for 2 types of devices. The first was

one that you could hold in your hand and the second was one that could be plugged in to

a network connection. In order to support this kind of flexibility, the J2ME architecture

was modeled within three layers of software as shown below.


Figure 1-9. J2ME software layer stack [15]



The Java Virtual Machine (JVM) layer defines the implementation of the JVM

that is customized for a particular host operating system and supports the particular

configuration [15].









The Configuration layer defines the minimum set of virtual machine features and

class libraries that will be available for a "category" of devices. These devices represent

a particular market segment and can be thought of as the "lowest common denominator"

of the Java platform features that a developer can assume will be available on all devices

[15].

The Profile layer defines the minimum set of Application Programming Interfaces

(APIs) available from a category of devices. Profiles are implemented "upon" a particular

configuration. Applications are written for a particular profile and should therefore port

to any device that conforms to that profile [15].

The configuration that defines small, mobile devices is called the Connected,

Limited Device Configuration (CLDC). Examples of CLDC devices are cell phones and

pagers. These devices will have memory between 160 and 512 Kb and utilize the

Kilobyte Virtual Machine (KVM). A CLDC device will utilize either a 16 or 32 bit

processor and network connectivity often in the 9600 baud range or less [16]. The

Connected Device Configuration (CDC) is considered to be the fixed type of device that

is always connected but still relatively resource poor. An example of this type of device

would be a WebTV. The CDC is a superset of the CLDC which ensures their

compatibility [15]. Figure 1-10 shows the relationship between the various

configurations.

The KVM is the virtual machine that is supported under the CLDC. CDC still

uses the classic virtual machine for 32 bit architectures and large amounts of memory

[14]. The essence of the KVM was to develop a new set of core classes that are

considerably smaller than what was previously installed by the runtime environment.









Development of the KVM originated as a project to create an execution engine for the

Palm series of devices. This project was known as the Spotless System [14]. The

Spotless System development team soon discovered that the size of the runtime

environment is derived mainly from its runtime libraries.


Figure 1-10. Relationship between J21ME configurations and J2SE [15]



The Spotless system team then extracted classes that were too bloated or not as critical to

the system. The primary features eliminated are as follows [16]:

* Java Native Interface- native functionality is implementation dependent
* User-defined class loader- CLDC will have a class loader that cannot be overridden,
replaced or reconfigured by the user
* Reflection- consequently no RMI, serialization or any features reliant on Reflection
* Thread groups and daemon threads- multithreading is supported but not these features
* Finalization- no finalization of class instances
* Weak References
* AWT- limited user interface classes developed from the javax.microedition.lcdui
package
* Floating point- long integers are enabled


Classes outside
J2SE do not use the










The classes that are not specific to CLDC are subsets of J2SE 1.3 classes [14].

The remaining classes are specific to CLDC and are found in the javax.microedition

package. This facilitates separating functionality that is dependent on these libraries

which aids in porting code.

Currently, there is only one profile specified for CLDC. The Mobile Information

Device Profile (MIDP) is the profile that adds specific classes the core set of CLDC

libraries. These classes are usually interface classes, persistence mechanisms, and

messaging infrastructures among others [14]. The requirements of a profile are in

addition to those specified by CLDC. The MIDP minimum display requirements are

listed below [17]:

* Screen-size: 96x54
* Display depth: 1 bit
* Pixel shape (aspect ratio): approximately 1:1

The goal of the consortium that created the MID profile was to create an open

third party application development environment for MIDs [17]. The high level

architectural view of the relationships between the layers are represented in Figure 1-11.

Three types of applications could run on this type of device. The first is a MIDlet.

A MIDlet uses only those classes defined by the MIDP API. The OEM-specific

applications are dependent on those supplied outside of the MIDP specification. Native

applications are those built on top of the system software provided by the device

manufacturer [17].

Jini

The Jini concept was born at Sun Microsystems as a complementary technology

to its Java programming language. The early 1990s saw the internet explode in


































Figure 1-11. High Level Architectural View MIDP Device [17]



popularity and success as it was adopted by the mainstream public as a way to access

information. This "information" has since manifested itself in many forms from email to

video. The information is a result of providing a service over a network, in this case the

internet. The end user must search out and find what he/she is looking for or use some

entity to facilitate that job such as a search engine.

In its most simplistic terms, the vision for Jini was to enable a Jini "device" to

become part of a network and share the resources that are available on that network

without administration by the user or anyone else. The physical devices on the network

look and feel as if they were attached to the user's Jini enable computing device. The

only requirement is finding a reliable transport mechanism and "plugging in." This

vision is an extension of the pervasive computing paradigm that includes not just

traditional PCs but any device that may have a "service" to offer. Embedded devices


OEM-Specific Native
MIDP Applications Applications
Applications
OEM-Specific
Classes
MIDP

CLDC

Native System Software

MID









may participate. One example is a Jini network for the home. The household appliances

may become part of a Jini network along with the desktop personal computer. Jini,

therefore, is a network-centric architecture specification that includes specific software

programming paradigms. This is an important concept to grasp in understanding the

potential for Jini's use and deployment.

Jini's technology foundation lies in the Java programming language and other off-

the-shelf concepts. Some of the key Java components include Remote Method

Invocation (RMI), Object Serialization, and strongly typed interfaces. One of the

concepts incorporated into Jini include a distributed storage model used for retrieving and

storing objects that is based on the Linda System from Yale University [18].

Jini can be understood as a network paradigm that centers around five general

ideas [18]:

* Lookup
* Leasing
* Remote Events
* Transactions
* Discovery

Lookup refers to the process of interacting with the Jini network to find out

information about the network. The services that join the network and the infrastructure

that manages is collectively known as a Jini Federation. The lookup service functions in

many ways as a name server by mapping a variety of descriptive parameters to a

particular service. The Jini lookup service, however, provides a much richer set of

semantics than just a mapping of string attributes to objects [18]. Jini's lookup service

understands a wide variety of search parameters including object type, interfaces, and

super and sub classes. The lookup service provides end users with a substantial list of









potential services available within the federation. A service that is made available on the

network must first join the lookup service. The join process is accomplished through an

interface that registers the service with its service object. The service developer provides

this object. The service object includes various attributes describing the service and a

proxy. The service proxy is a serialized object that is downloaded to a client's virtual

machine. The proxy provides a client with the required interface to utilize that service

[18]. The implementation of the proxy is left to the developer. The proxy may be the

application itself which is downloaded to and executed on the client. Another proxy

alternative may be a special protocol which allows the client to "talk" to the service. The

underlying design philosophy for the proxy abstracts the particulars (i.e. location, type of

connection, etc.) of a service.

Leasing addresses many issues associated with any distributed environment such

as fault tolerance, consistency, and reliability. It can be assumed that any networked

system will encounter failures for both the network and service. The ability to

distinguish a failure from network delay can be challenging in a distributed environment.

Jini's leasing mechanism attempts to deal with these issues by creating a "relationship"

with the lookup service. This relationship is guaranteed only for the agreed upon lease

period. This allows the network to clean up old services that have left the network or

possibly experienced some type of failure. Implementation of the leasing mechanism can

be carried out by the service itself or delegated to a third party. The third party negotiates

and administers the lease on behalf of the service with the lookup service. Leasing is an

important component to the Jini federation's ability to self-heal and manage itself [18].









Remote events refer to the way that Jini manages the communication links in its

distributed environment. A Jini federation is defined by the network on which it lives.

Communication must take place between the various entities including clients, service

providers, and administrators. There may be issues relating to the state of connectivity

for a receiving party. Communication needs to take place asynchronously so that

services or clients do not have to continually poll for messages or events. A client or

consumer looking for a printer may join the federation when one is not available. A

printer may come on line after the client has queried the lookup service and it should be

notified of this event [18]. The Jini remote event facility determines how these types of

events are handled and sent to the appropriate entity.

The Jini transaction manager ensures the data integrity between the distributed

components of the federation. Distributed transactions are well understood in the

database arena and a similar approach is taken within Jini. A two phase commit protocol

is used to define a prepare phase and then a commit phase. The only alternative is to

abort the transaction. The major difference between existing database protocols and Jini

is that the actual implementation is left to the developer. In other words, Jini says

nothing about what must happen in each phase. The Jini transaction protocol simply

gives the interface that must be used and followed to carry out distributed transactions

[18].

The Jini discovery protocols are at the very core of Jini and provide the

mechanisms by which Jini services and applications bootstrap themselves into Jini

communities when they start up [18]. Discovery is the loose term applied to the process

of services first "seeing" the federation (This includes discovering the available lookup









services and finding where they are located). There are basically two types of discovery

procedures. The first type is suited for "serendipitous" interaction between services and

lookup services [18]. This situation occurs when there is no a priori knowledge of any

existing infrastructure on behalf of a service provider or the lookup service. This form of

discovery utilizes the Internet Protocol (IP) multicast. A service creates a message

probing a certain depth of the network. This probe is an inquiry regarding all available

lookup services that could accommodate the service registration. Conversely, a lookup

service may be created that wishes to advertise its availability to services that already

exist on the network (Both of these scenarios use an event listener to asynchronously

check for replies to inquiries sent out by the multicast). The scenario progresses by then

utilizing the Jini join protocol. This protocol further establishes the relationship between

service provider and the lookup service. The join protocol deals with leases, registration

and any other administrative issues of the federation.

There also exists a direct discovery protocol. This protocol is used when a service

contacts a lookup service that is already known. A unicast message is sent to the known

address of the lookup service. The lookup service replies with its own service proxy .

The idea of service discovery combines the elements of both discovery and

lookup. A client first must become aware of the Jini federation. This is accomplished

during discovery of the Jini network. The client then must utilize the federation in some

way. The use of the federation or consumer activity is accomplished through the lookup

process. A question that arises is: can the lookup process allow a dynamic

reconfiguration of the client that will allow it to more efficiently utilize the services






32


offered by the Jini network? We will attempt to answer this question with the design of

the Virtual Thin Client within a Jini federation.














CHAPTER 2
PERVASIVE COMPUTING AND MOBILE DEVICES

Definitions

Pervasive computing is a broad term that refers to the creation of a computing

environment that focuses on users and their tasks rather than the devices and technology

that underpin the environment [21]. Pervasive computing has its roots in the Ubiquitous

Computing effort that originated at Xerox in the early 1990s. This early effort sought to

increase the availability of computing devices within our environment but at the same

time reducing our (i.e. human) interaction with them [22]. The Ubiquitous Computing

concept evolved into a framework for developing this type of environment. The idea was

to remove the computer from its use in the context in which it was meant to perform.


Devices that allow users to access information are becoming more diverse and

more widely available. The introductory chapter of this research introduces a wide range

of technologies that help to coalesce the pervasive computing environment. The goal of

this type of computing is to bring relevant information to the user when it is needed in

whatever environment that may be. This loose interpretation can be further refined to

include several critical components that help define the pervasive computing

environment.

Pervasive computing paradigms give the user access to data and applications in

scenarios previously thought improbable. The devices are smaller, mobile, and most

importantly connected, by some means, to the "network." The development of wireless









technology has created opportunities for a multitude of mobile devices to become part of

the pervasive computing paradigm. The question remains how to effectively present

information in the most productive way. This is the fundamental challenge of pervasive

computing. This challenge has sometimes been referred to as context-aware computing

[19]. The following scenario from Huang (et al.) aptly describes pervasive, context-

aware computing [19].

Opening your refrigerator to take out a soda, you notice that there is only
one can left. You scan its UPC with the scanner attached to your
refrigerator. This action adds soda to your shopping list. You plan to
have guests over this weekend, and make a note on your ScreenFridge that
you need to replenish your supply of drinks by Friday.

The next day, on your drive home from work, you happen to approach a
local supermarket. Your GPS-enabled AutoPC, previously informed by
your refrigerator that purchases need to be made, signals that you are near
a grocery store, and if it is convenient, that you should stop by the
supermarket on the way home. Suppose you do not act on the
opportunity, and Friday rolls around and you still have not visited the
supermarket; in this case, a message to buy drinks is sent to your pager, or
an alarm is triggered in your PDA, or both.

This represents a To-Be model of pervasive computing. A key point to

understanding the power of pervasive computing involves delivering information in a

dynamic fashion that is most useful to the user. The temporal and spatial boundaries

established by the demands of a situation must be captured by a pervasive computing

system if it is to become truly useful. The information must be supplied when it is

needed and in combination with where it is needed.

Conceptually, pervasive computing is a very good idea, but how will it be

implemented? There must be an element of smartness injected into a pervasive

architecture. The devices should know what to do when they are told to do them with

little intervention from the user.









Deficiencies

The pervasive computing environment gives users the freedom to obtain a wealth

of services with little knowledge of how, where, or when those services are granted.

While very attractive from a user's standpoint, the concept has a number of obstacles to

overcome. The pervasive computing environment should be put into context with the

present capabilities. The as-is model is defined by numerous heterogeneous devices

ranging from wearable devices to conventional computers, network connectivity that is

intermittent (at least for mobile devices), and interactions that are limited by the

administrative domains inherent on available networks [21].

Mobile devices still suffer from the need to use low power consumption

components. Power is a limiting factor for how long a device can communicate with the

network and still support a computational work load.

Wireless bandwidth does not support high data rate applications and certainly not

multimedia applications. The emergence of new generation wireless technologies such as

3G, Bluetooth, and IEEE 802.11 should help to alleviate this problem, but gaps in

coverage still remain that must be dealt with. A mobile device still needs to operate in

both connected and disconnected states.

The diverse nature of mobile devices makes it challenging to ensure that

communication occurs regardless of the underlying operating system, wireless

connection, and application. Platform neutral technologies such as Java are rendering

these issues irrelevant, though performance may still be at risk.






36


Convergence of New Technologies

Presently, there is a convergence of many new technologies along with some

older ones. This convergence is growing rapidly to support the notion of the pervasive

computing environment. Many issues are being addressed with the introduction of

improved device architectures, new protocols, and rapidly adopted standards.














CHAPTER 3
VIRTUAL THIN CLIENT APPROACH

A large number of mobile devices are unique and capable of processing data

locally. These devices range from PDAs to laptops. However, a class of devices still

exists that is mobile, yet has limited resources for processing data and/or obtaining the

necessary connection to the network. This research suggests that the Virtual Thin Client

approach allows these resource "poor" devices to give users the look and feel of a much

more powerful computing device.


Problem

Device connectivity is improving with the implementation of new generation PCS

technologies such as 3G. This means that a greater breadth of devices will achieve

connectivity for data transmission even though the capability of those devices has not

improved substantially. The MID profile from Sun Microsystems details the following

device specifications [17]:

* 128 kilobytes of non-volatile memory for components
* 8 kilobytes of non-volatile memory for application-created persistent data
* 32 kilobytes of volatile memory for the Java runtime
* two way wireless network connection (possibly intermittent)

It is clear that this limited configuration will be unable to run many applications

because of required memory and/or storage capacity. These devices are specified with a

Java virtual machine that does not contain a large number of the classes required for

many Java APIs such as Jini. The storage available on these types of devices allow for a

sparce operating system and few resident programs. With these constraints, therefore, the









device is excluded from the very pervasive environment that its mobility was designed to

give.


Uniqueness

Thin client technology is available for numerous platforms including certain

mobile devices. Service technology is now available in devices ranging from Jini

federations to Bluetooth piconets. The intent of this research is to show the feasibility of

using thin-client technology within this emerging MIDP class of devices. Once the client

viewer has been developed, testing of the various protocols will determine the

efficiencies associated with each.


Architectural Vision

The VTC system is viewed as part of a larger effort to put in place the technology

to make Pervasive Computing a reality. The VTC will allow device access to a wide

range of network services traditionally reserved for far more capable devices. The VTC

is a piece of that architecture that includes robust service discovery, high bandwidth

network capabilities, and intuitive or smart interfaces. Figure 3-1 shows the conceptual

vision of this pervasive environment.

The notional architecture captures the intent of the device to be connected to a

much more robust environment than a simple voice/data network. The Pervasive

Computing paradigm comes into play when 1) the device seamlessly discovers that there

is a network of services available. Then 2) the device requests a service that can not be

executed locally due to its limitation of resources. This does not present a problem since

3) the service is sent to the VTC server where the service object is executed remotely.
































Figure 3-1. Virtual Thin Client Global Architecture


Then 4) the device creates a network connection to the VTC server that seamlessly

provides the user with the look that everything is happening right on his/her device.

Perhaps 5) other mobile devices take advantage of the same services yet also need the

help of the VTC server to execute those services.

This vision is an encompassing view of the necessary network hardware and

software to implement such a solution. This research is focused on implementing the thin

client technology for the mobile device that will play a vital role in completing the link

between mobile devices and powerful fixed networks.


Design Requirements

The viewer component will be developed from the base classes provided by

CLDC and the APIs of MIDP. The current Java viewer for VNC makes use of the AWT









class which is not supported by CLDC or MIDP. The viewer needs a reliable transport

layer and the ability to read a byte stream. This data will then be rendered to the screen

utilizing the javax.microedition.lcdui package. There are two basic sets of classes in this

package. A high level API, which is used to guarantee portability to other devices and a

low level API used to access the display directly. The VTC viewer will make use of the

low level API since this contains the Canvas, Image and Graphics classes. Events can

only be managed by a Canvas class so this is another important reason to use the low

level API.


Limitations

The VTC will be highly dependent on the client device capabilities. The MIDP is

designed to address some compatibility issues but this is primarily within the MID class

of devices. There are other classes of devices that will utilize other J2ME profiles that

have not been specified as of this writing. The PDA profile is under review by the Java

Community Process and will add functionality specific to that class of device.

This is of primary importance due to the uniqueness of differing types of user

interfaces. Many of these devices will support some type of pointing device and many

will not. A device may have a virtual keyboard for inputting text. The typical cellular

phone will still use a keypad that utilizes a single key for numerous character inputs.

This becomes a critical issue when handling events within the VTC architecture.














CHAPTER 4
IMPLEMENTATION

Technical Summary

The Virtual Thin Client will be implemented utilizing the Software Development

Kit Drop 7 provided by Motorola [25]. The core development language will be in the

Java 2 Micro Edition utilizing the various packages that are relevant to the individual

design modules. The focus of this design will center around the creation of a VNC client

that is compatible with MIDP specification associated with Sun's CLDC. The client

must be capable of accepting the data that is sent from the server and rendering it to a low

level graphical interface. Events must be captured on the client side and be processed to

ensure that the intended "key" is passed back to the server. The code must be optimized

to create the smallest footprint possible. This will entail eliminating as much non-

essential functionality from the existing VNC protocol to include authentication and

encryption. This will also entail testing and measuring the appropriate data encoding

format for the best bandwidth usage and rendering time.


Client

The VTC client software must be developed. A viewer for the J2ME CLDC

platform does not currently exist. A Java implementation for a VNC viewer does exist

and this is used in this thesis as a template for the VTC client. There are, however, major

implementation differences that needed to be resolved.









Class Mapping

The current VNC viewer written for Java makes extensive utilization of the Java

Abstract Windowing Toolkit package. This includes the API's to enable event




Table 4-1. Class summary of the javax.microedition.lcdui package

Class Description
Alert An Alert is a Screen that shows data to the user and waits for a certain
period of time before proceeding to the next Screen.
AlertType The AlertType provides an indication of the nature of an Alert.
Canvas The Canvas class is a base class for writing applications that need to
handle low-level events and to issue graphics calls for drawing to the
display.
ChoiceGroup A ChoiceGroup is a group of selectable elements intended to be placed
within a Form.
Command The Command class is a construct that encapsulates the semantic
information of an action.
DateField A DateField is an editable component for presenting date and time
(calendar) information that may be placed into a Form.
Display Display represents the manager of the display and input devices of the
system.
Font The Font class represents fonts and font metrics.
Form A Form is a Screen that contains an arbitrary mixture of items: Images,
non-editable StringItems, editable TextFields, editable DateFields,
Gauges, and ChoiceGroups.
Gauge The Gauge class implements a bar graph display of a value intended
for use in a Form.
Graphics Provides simple 2D geometric rendering capability.
Image The Image class is used to used to hold graphical image data.
ImageItem A class that provides layout control when Image objects are added to a
Form.
Item A superclass for interactive components that can be added to a Form.
List The List class is a Screen containing list of choices.
Screen The common superclass of all high-level user interface classes.
StringItem An item that can contain a string.
TextBox The TextBox class is a Screen that allows the user to enter and edit
text.
TextField A TextField is an editable text component that may be placed into a
Form.
Ticker Implements a "ticker-tape," a piece of text that runs continuously
across the display.









management, image rendering, and other related graphical capabilities. Since the MID

profile for CLDC does not contain any of the AWT classes, a major development theme

was to enable these capabilities. Table 4-1 describes the current graphical capabilities

found in the javax.microedition.lcdui package. This package contains the API's that are

available for constructing graphical interfaces for the KVM.

Flow of Control

The flow of execution occurs from the initial MIDlet that is run as an interface on

the device. The current interface is located within the clientShell.java class. This class

establishes the main screen. This main screen is composed of a list object that is

implemented with 2 choices. The VTC choice is representative of any service that could

describe what the user is looking for on the network. Once chosen, the Virtual Thin

Client is instantiated and the thin client process takes over as the currently executing

MIDlet. Figure 4-1 shows the initial screen that the user sees upon activation of the

clientShell.

VtcViewer

The class that acts as the parent to the VTC is the VtcViewer class. This class is

similar to the VNC java viewer in that it creates the necessary threads for executing the

RFB protocol as well as the graphical logic for creating the screens. The primary

function of this class is instantiating the vtcCanvas class and performing the initial

handshaking activities with the server. Once the initialization is complete, control is

passed to the vtcCanvas class, which is the primary workhorse of the VTC.


































Figure 4-1. Start up screen for the VTC


VtcCanvas

The vtcCanvas class performs the necessary rendering computation of the server

pixel data so that the appropriate screen can be drawn. This class was perhaps the most

challenging to implement using the J2ME libraries for MIDP. The absence of the AWT

package meant that the Canvas class of MIDP would be the only interface for drawing to

the screen. The lack of the ColorModel, ImageProducer, ImageConsumer classes meant

that the rendering would all occur within the vtcCanvas methods.

The vtcCanvas implementation needs to thread its main processing loop. The

method named processNormalProtocol() creates a thread for this loop. This thread

checks for incoming messages from the server, checks for the type of message, then









passes this on to the appropriate case statement for handling. The following figure

illustrates the critical functionality of this method.


Figure 4-2. Flow chart for the main processing loop thread


This method contains the encoding scheme that defines how the client will

process incoming pixel data. The VTC implementation contains four encoding schemes

that are available to VNC clients. These include raw, RRE, CoRRE and Hextile. Each of

these methods require an acceptable pixel data format. The data received from the server

must be in a format compatible with the available API's used by the MIDP Canvas class.

The MIDP Graphics class has a method named setColor() that takes as an argument the

red, green and blue components of the requested color. There is no ColorModel class so,

the VTC utilizes its own ColorModel class. The VTC ColorModel class contains one

member that is a three dimensional array. This array contains the components of each


no









color hue based on the GBR233 format. This format uses an eight bit representation of

the color spectrum. It provides 255 colors and is used in situations where there are

network bandwidth concerns. The VTC client requests pixel data in the GBR233 format.

A specified frame color is sent as an unsigned byte representing the color. This color is

read from the server and translated into the appropriate ratio of red, green and blue

components utilizing the VTC ColorModel. This approach is common to all encoding

schemes. Once data is received by the main data loop, a flag is set and the repaint()

method is called to update the screen.

The necessity to thread the main processing loop is due to the method for event

management in MIDP. Each low level screen graphics is required to provide its own

implementation of methods for event management. The keyPressed( ) method is an

interface that each application must provide in order to handle key events. These

methods are collectively known as "event delivery" methods [17]. These methods are all

called serially so that no method will be called prior to a previous method's return. This

is true for the run( ) method of any Runnable object. This design ensures that the main

loop's call to the repaint( ) method will return prior to the handling of an event that will

change the current state of the display. This prevents any inconsistent display occurring

that would otherwise confuse the user.

Event Management

Event management is implemented in the VTC design utilizing a state machine

that interprets user intentions based on timing mechanisms and the last state. The

fundamental challenge was twofold. The first challenge was capturing user intended

inputs with as little resource overhead as possible. The MIDP provides the event delivery

methods that the software designer can use to manage events. This software









implementation can be as sophisticated as needed. These methods were intended for use

as in place logic, typically using switch statements to find the correct action to take. This

could be thought of as the "fire and forget" approach. The VTC needed a "fire and

remember" approach. A general schematic of the VTC key event management is shown

in Figure 4-3.

The general premise of this approach tries to process events locally so that the

application that is executing on the server will understand the user's intent. An

alternative approach could have been to decouple this processing from the client and

move it to the server directly or within a proxy.

The assumption is that the application expects events that correspond to a

"normal" desktop environment. In this way, the keys that are sent to the server are


Figure 4-3. State Diagram for key event management for the VTC


Key Event Consumer
Thread


Key Event Producer
Thread









the characters that one would expect from any desktop keyboard. The exception is in the

generation of Meta key events. The MID does not currently have any capability to

change the meaning of a keystroke by holding down another key. This does limit the

utility of using the thin client for certain applications that would require this range of

input. The context of keyboard functionality is an interesting area and is briefly explored

in the following paragraphs.

The MID keyboard is hard coded into key codes which represent the physical

pressing of a key. The key code is passed to the to appropriate event method for

processing. The keyPressed( ) method is the event method implemented in VTC for

starting the initial event processing. An application that is normally expecting the input

from typical computing input devices will not understand the meaning of ITU codes that

represent MID key presses. Therefore, the logic must be put in place to ensure that the

intended event is the one generated and sent to the server. This is true in the case for

"non-MIDlet" applications. What would happen if the application being executed on the

server side was a MIDlet? The processing logic would lose its contextual meaning and

would need to be switched off. This was accomplished by setting a flag in the logic code

but it requires cooperation on behalf of the network for notification of the type of input

logic required.

The state machine logic captured in Figure 4.3 describes the processes that are

established by the vtcCanvas class. The logic captures key events with a timestamp and

passes this information to a method that checks the current state of the thread. The

method then waits for any additional events from the same key code. If the same key

code is received before the timeout, then this means that a new intended key must be









saved as the latest key event. Once the timeout value has been reached, the last key event

saved in the queue is written to the server. The actions that would cause the event to be

written prior to the timeout would include the receipt of an event that was different from

the latest saved event. Another action would be the receipt of an event that was in excess

of the available options for a particular key. For instance, a particular key may represent

one numeral value, three lower case letters and three upper case letters. If this key was

pressed eight times, then the last upper case letter would be written to the server and the

number value would be the latest key value stored for the next entry.

A flag can be set to turn this type of local processing on or off. It may be the case

that events need to be sent directly to the server. This may happen when the server

executes a MIDlet instead of a "normal" application.















CHAPTER 5
TEST AND EVALUATION

The VTC client code was completed and run utilizing a laptop and IEEE 802.1 lb

network connections that simulated over air data transfer. A primary goal in conducting

experiments for the VTC client was to characterize the capabilities that define the present

configuration. The VNC protocol has been viewed as a relatively inefficient protocol

concerning network bandwidth and CPU rendering operations so it is important to

document some of the initial capabilities of the implementation. The performance can be

depicted by creating a view of the components that comprise the relationship that exists

between the client and the server. We use this conceptual view, illustrated below, to

guide the design of some of our experiments. These are serial events that are dependent

upon the previous event's completion. In effect, this creates a pipeline that determines

the efficiency of the VTC system.













Client even Client request service t Server repone Clent rendering
generation delay network delay network delay t e





Figure 5-1 Conceptual view of VTC performance pipeline









Testing Environment

The VTC client is executed utilizing the MotorolaSDK Drop 7 version of the

MIDP emulator. This emulator is run on an IBM ThinkPad laptop computer with the

characteristics shown in Table 5-1.




Table 5-1. Emulator host environment
OS Name Microsoft Windows ME
Version 4.90.3000 Build 3000
OS Manufacturer Microsoft Corporation
System Name WIRELESS-23
System Manufacturer IBM Corporation
System Model IBM ThinkPad 1440
System Type X86-based PC
Processor Pentium(r) Processor GenuineIntel -266
Mhz
BIOS Version ACR79P54C 415V3.0
Total Physical Memory 95.45 MB
Total Virtual Memory 322.45 MB
Page File Space 227.00 MB
Network 802.1 lb

Goals of Experiments

The objective of studying the pipeline performance is to identify bottlenecks in

the overall system. Individual testing goals include characterizing the performance of the

VTC in terms of the most efficient encoding scheme, rendering times, maximum update

refresh rates and impact of the event handling scheme that was implemented. All of these

measurements can be thought of as parameters that describe the performance and cost of

utilizing this system. The performance parameters are in terms of rendering times and

delays for rendering new updates from the server. The robustness of the system will be

tested by stress-testing the client through an increasing load of server updated screen

frames. The cost of the system can be measured in terms of the bandwidth utilized by the









system. Bandwidth utilization is actually under consideration as an actual billing scheme

for users of 3G data networks.

Experiment I

Initial screen rendering

The initial screen rendering time is a measurement selected for its measurable

efficiency of a desired encoding scheme to render a given data set. The initial screen was

isolated within the main processing loop and timing calls were inserted at the appropriate

points to capture the system cpu time. This data was used to determine the efficiency of

the individual encoding considered. The measured encoding schemes were RRE, CoRRE

and Hextile (previously defined in chapter 1). Each encoding scheme was measured

twenty times for the required time to generate the initial screen in Figure 5-2.

This program is a test program the takes in simple text commands and returns a

simple text based response. The server side architecture utilized was generated from the

VNCj server written by Tal Liron from Amherst Univesity [24]. The server was

modified to render a display in a screen size that would fit on the phone display. The

image size generated was 104 by 96 pixels. In order to isolate the network dependencies,

the server was run local to the client. This was done to better test the rendering engine of

each encoding scheme. The initial results are shown in Figure 5-3.

From the results, it is clearly evident that the Hextile encoding scheme

outperformed the other two encoding schemes over this 20 run sample. The average time

for the Hextile scheme was 13.696 seconds with a standard deviation of 564ms. The

average time for the CoRRE scheme was 14.529 seconds with a standard deviation of

457ms. Lastly, the average time for the RRE scheme was 14.919 seconds with a standard

deviation of 596ms. There were no other active programs running at the time of














(.....4..


Figure 5-2. Initial screen rendering test program


Figure5-3. Initial Rendering Time Results


Initial Rendering Time (loopback)

18000
17000
16000
o 15000 -- -\-
14000
g 13000
12000
CO-- LO Ir- M O LO r- )
- Hextile
--CoRRE Run
RRE










measurement that could have adversely affected the outcome of a particular scheme.

This configuration was measured on a local loopback with the server.

The same parameters were then measured on the Harris lab 802.11 wireless LAN

network. The server was running on the Ocala machine within the Widows 2000 cluster.

These measurements were taken to observe the system behavior when an actual wireless

protocol was utilized. The results are shown below.


Initial Rendering Time (802.11)

12000

11500 /

o 11000- IN "N--

S10500

10000

9500
1 2 3 4 5 6 7 8 9 101112 13141516 17181920
Hextile
CoRRE Run
RRE


Figure 5-4. Initial Rendering Time (802.11)



The mean time for the Hextile encoding scheme was 10.755 seconds with a

standard deviation of 315 ms. The CoRRE scheme average was 10.853 seconds with a

standard deviation of 224 ms, only slightly better. The RRE scheme produced an average

rendering time of 11.151 seconds with a standard deviation of 219 ms.









Conclusion

The initial screen rendering times demonstrate the efficiency of the system to

generate a display without buffered data. The data shows that the Hextile encoding

scheme has an advantage over the other two schemes by a small percentage.

Experiment II

Data throughput

The capability of the VTC system to respond to continuous input from the server

is useful to understand the upper bound of continuous rendering capability. The

parameters useful in measuring the throughput of the system was the number of frame

updates passed by the server on a continual basis. A simple counter program was used on

the server side to pass frame updates at an increasing rate based on client capacity. The

measurement will look at not only the number of framebuffer updates but the efficiency

relating to packet transfer as well. The measurements were taken for 1 minute intervals

(wall clock time) measuring both the number of framebuffer updates requested and the

total byte size relating to the packet transfer. These measurements were base-lined

against an existing Windows version of the VNC viewer that is written in C. A screen

shot of the client device is shown if Figure 5-5.

The number of packets were measured using a packet sniffer software package

entitled CommView from TamoSoft, Inc [26]. CommView was configured to monitor

the incoming TCP/IP session of a remote IP address. Figure 5-6 shows one screen of the

resulting data that CommView offers. This was the IP data captured during the Hextile

encoding measurement.





































Figure 5-5. Counter application for throughput measurement


FiI le ear '_e" l Ic.I .rig: ...Il : Hel


L 1i :I.il.' *J owr di

[] -IP 5 It .- |i F .-r i|, L.:.g.u.- 6. Co mmu ie-..
L,:..: l [F | F I -,,,.-. | I a n I E-.i m I e,,, 'nr. I :---F:.;,.:. F,. I P.:.,t-. H.':'.vr ,, I E, l... |
I: .- I- - I- 11' ': I':'- r ,,,l:, 4r -.-

IC Fi..IJ I:,I IF -.:l .I .1 ,,-i r i .I i... i -',1 ':' -,. '- i i i R 4. 4 Ii:.l: .F .

Figure 5-6. CommView window


The results of the throughput measurements are listed in the following table.









Table 5-2. Comparison of VTC throughput
Test Parameter # of packets bytes # of frame updates
RRE 436 46275 84
CoRRE 417 44035 81
Hextile 437 46258 85
WinVNC 3913 409720 738


Conclusion

It is obvious that the efficiency of each VTC encoding scheme is relatively the

same when compared to a windows vnc viewer. An examination of the pipeline would

suggest that the inefficiencies are located within the client rendering engine since the

other parameters (i.e. server side service, network transport, client input) were constant

for all trials.

Experiment III

Complexity of input

The utilization of the state machine to capture user input has an associated cost in

terms of delays, message passing and local processing resources. The payback is in terms

of fewer messages passed to the server hence bandwidth conservation. The other

investment return is allowing the device to interact with applications that otherwise

would not understand or interpret the limited input of the client. This means that the

VNC server and protocol can be used without any changes which contribute to a greater

degree of portability of the VTC system over various mobile devices that are constrained

by proprietary or limited input interfaces. There are several factors impacted by the use

of this approach. The one factor chosen to measure here is felt to be critical in that it

directly relates to the rendering response time. The user is now faced with a complexity

factor associated with each keystroke. Keys no longer have one meaning but in fact can

represent several characters. The delay in sending this event message is related to the









individual complexity of the key "elements" that the physical keystroke represents. For

example, the number "7" key can represent nine different characters. The method taken

in measuring the cost of implementing this approach is found in dicrete event simulation.

We suggest that the probability of selecting any one character representation is equal to

any other. Admittedly, this may not be true within the context of certain languages

and/or applications. One example that comes to mind is password entry. There is no

significance in ordering or meaning of characters in password entries. Therefore, this

assumption seems reasonable in this context. The VTC model can define the delay

associated with entry of characters by the following mathematical equation.

Timeevent generation = (Timeto press element) + Queue delay + Timeout

The Queue delay is determined by the length of delay within the thread that is

checking for new key entries. The worst case is that the queue was just checked and the

event must wait an entire sleep cycle prior to being written to the server. The best case is

that the queue is checked on the very next cycle after the key was placed so there is

essentially zero delay. The Timeout is a constant value but the Timeto press value is the

time that it takes to press and release a key. This will obviously vary around some value

that we have chosen to be 500ms. We have assumed that this value is normally

distributed about 500ms. Essentially, some days we push buttons faster than others! The

element is how many times we have to press a key to get the needed character.

The delay for any individual key is easier to see but what about the overall system

delay over time? Assuming that we are just as likely to enter any key over time, the best

way to see the impact is to simulate the selection of keys and delays using a Monte Carlo

simulation. A Monte Carlo simulation essentially allows us to access a probability










density function by generating a random number. We assign a density (i.e. uncertainty)

to a variable and the simulation samples the density based on a random number generated

during the simulation. This runs over a certain period of iteration. We, therefore, get a

statistical sampling of a problem that otherwise might be mathematically intractable.

We ran 2 simulations using a "fast" key press and a "slow" key press. The

outcome or final event delivery delay was measured over 1000 iterations of the

simulation. The results for the fast simulation are shown below.


Forecast: Total key event generation time
1,000 Trials Frequency Chart 0 Outliers
057 57

043 -------- ------------ ---------------------------------- 42 75

0 29 Il Illllll .. ....... ....................................... 42 75

S01414------- 25

0000
1,161 89 2,144 36 3,126 83 4,109 30 5,091 77
milliseconds


Figure 5-7. Frequency chart for event generation time (fast)


Table 5-3. Statistics for "fast" simulation
Statistics Value
Trials 1000
Mean 2,052.15
Median 1,855.0
Mode 7
Standard Deviation 681.33
Variance 464,207.42
Skewness 1.09
Mean Std. Error 21.55











The "slow" key press mode data results are as follows. The mean time of

increase for utilizing this scheme was 2.052 seconds with a range from 1.161 seconds to

5.091 seconds. The full statistics are listed below.


Forecast: Total time for generation of key event
1,000 Trials Frequency Chart 9 Outliers
049 49

037 ------ ---- --------------------------------- 36 75
-,
C1

025 ...... ,. . .. .,. . .. ... ........................ 24 5
012 ------------------------------ 12 25

000 0
1,445 12 2,498 18 3,551 23 4,604 29 5,657 34
milliseconds


Figure 5-8. Frequency chart for event generation time (slow)


Table 5-4. Statistics for "slow" simulation
Statistics Value
Trials 1000
Mean 2,891.76
Median 2,672.21
Mode ---
Standard Deviation 1,132.39
Variance 1,282,316.45
Skewness 0.54
Mean Std. Error 35.81



Conclusion

The event capture mechanism implemented by the VTC system incorporates a

typical delay between 2 3 seconds based on our current model. This assumes a

randomized selection of characters over time (i.e. a password entry) that will "cost" the

user in delay time.









Experiment IV

Dynamic pipeline measurement

The effect of the pipeline can be measured statically as captured in the previous

experiments but this may limit some observation that occurs when events and updates are

sent across the network. This experiment will capture the time associated with event

generation to the time associated with that events display to the user. This captures the

entire pipeline and allows us to dissect any major bottlenecks.

The approach to this experiment will be to insert timing calls on both the client

and server side to isolate the particular operations that are pertinent to the pipeline

analysis. The effect of input on the client side is relatively well understood so our

measurements will be bounded by the event message sent to client until the results of that

event are returned and rendered to the client display. The benchmark for this experiment

will be the use of the text program input used in experiment I. The "jump" command will

be used as the baseline command. The command will be measured by isolating the

individual events that comprise the final command to execute a "jump" statement. This

simple statement simply returns a text statement to the screen. Each event will be

measured from the time that the event message is generated to the server until the next

framebuffer is requested. This will allow a dissection of the time involved in each event

and subsequent server action. An initial attempt was made to correlate the server time

with the client time but the inaccuracies of the system clocks prevented this analysis. The

system time differences were often greater that the periods that were measured. This

command was executed and measured for 4 trials.

The following figure shows the breakdown of the average render time for each


event.
























Figure 5-9. Average render time for "jump" events



The average client render time for each character is 432 milliseconds with a

standard deviation of 47 milliseconds. The updated screen after the command is sent

takes on average 8660 milliseconds.

Figure 5-10 shows the associated "network time" of each event. Due to the

system clock inaccuracies, this value is aggregated as a round trip for the event message

to the server and the return of its updated screen data. This value was relatively constant

irregardless of the display update that was rendered.


Ave Network Time

190
185
S180 -
0 175




"J" "U" "M" "P" send



Figure 5-10. Average aggregate network delay
Figure 5-10. Average aggregate network delay


=Average Render Time

10000
m 8000 -
o 6000-
. 4000-
H 2000-

"J" "U" "M" "P" send









The last component of the dynamic measurement is the server render time. This

is shown in Figure 5-11.


15 -
14.8







Figure 5-11. Server rendering time



Conclusion

The data seems to indicate that the server and network portions of the pipeline

delay are fairly constant. The server and network delay becomes relatively small when

the client is requested to update a large part of the screen. This is evident by the long

delays in initial screen rendering and when the jump command is executed by the server.

In both of these cases, the client rendering operation is over 98% of the delay.


Conclusions

The comparison of various encoding schemes would lead one to conclude that the

Hextile scheme has a slight advantage over the others in terms of efficiency and

rendering delays. The initial screen drawing on the 802.11 network was almost even for

the Hextile and CoRRE schemes but they were both clearly superior to the RRE scheme.


16.2
16
15.8
15.6
15.4
15 I


1 server render time









The most interesting data was the difference in rendering times that became apparent

after changing from a local loopback scenario to a remote server. There was a

approximate 21% decrease in rendering time when the server was no longer co-located.

This would suggest that the VNC cpu appetite was eating up significant resources when

located on a single processor.

The event implementation can end up costing the user an additional 2 to 3 seconds

per input over time. The Monte Carlo simulation showed that this delay would be present

on average per 1000 inputs. This should be viewed as an inherent limitation of the device

itself. The price to pay for mobility involves issues like limited I/O, battery life, etc. The

benefit gained from our implementation is a reduced burden on the network which could

translate into reduced operating cost. An alternate implementation is to push this

functionality to the server but then the issue of context becomes complicated for

application selection.

The pipeline analysis clearly points to the current KVM as a limiting factor in the

performance of the VTC. There is no capability for the VTC to copy a part of an existing

image and "move" it to a different anchor location. This is a limitation that is extremely

costly when the display scrolls up or down and a portion of the screen remains constant.

The VTC, however, must repaint all of the image since the ability to copy rectangles

from old images is not possible.

The overall capabilities of the VTC system can be viewed as somewhat limited.

The current implementation is nearly an order of magnitude slower in terms of

throughput when compared to a version that has the resources of a full desktop operating

system and associated hardware.






65


However, the MIDP class of device should not be considered as competitive to

the fixed device world. Initially, these limitations should be understood so that the

correct usage can be applied. The current VTC implementation will not replace your

desktop or even your laptop but it should allow the Pervasive Computing paradigm to

come one step closer to fruition.














REFERENCES


[1] Sybex, "Networking Complete," Network Press, San Francisco, CA 2000

[2] Thin Planet, "Thin Client Architecture,"
http://www.thinplanet.com/tech/generic.asp?f=TDnumber&k=s&v=TD104331,
Aug 1997

[3] Sinclair, J & Merkow, M, "Thin Clients Clearly Explained," Morgan
Kaufman, San Francisco, CA, 2000

[4] Montenegro, G., "Network Computer Reference Profile,"
http://playground.sun.com/-gab/talks/clei96/supplement/nc refprofile.html

[5] D'Haese, G, 9th Linux SIG Workshop,
http://www.ota.be/linux/workshops/19970315/nc/sld010.htm, Mar 1997

[6] Citrix Systems Inc., "ICA Technology,"
http://www.citrix.com/products/ica.asp Jan 2001

[7] Richardson, T. & Stafford-Fraser, Q. & Wood, K. & Hopper, A., "Virtual
Network Computing," IEEE Internet Computing, Vol.2 No.1, Jan/Feb 1998 pp33-
38.

[8] AT&T Laboratories Cambridge, VNC screenshots,
http://www.uk.research.att.com/vnc/screenshots.html, Jan 2001

[9] Shim, R. "2000: The year PDAs grew up,"
http://www.zdnet.com/zdnn/stories/news/0,4586,2665706,00.html Dec 2000

[10] Lin, Y. & Chlamtac, I., "Wireless and Mobile Network Architectures,"
John Wiley & Sons, Inc, New York, NY., 2001

[11] Micrologic, "3G Cellular Market Opportunities,"
http://www.wirelessdata.org/index/third/9904index.asp, Jan 2001

[12] PDABUYERSGUIDE, Inc "What is a Palm PC (PPC)? What models are
out there?," http://www.pdabuyersguide.com/ppc.htm, Jan 2001









[13] Mery, D. "Why is a different operating system needed,"
http://www.epocworld.com/techlib/techcomms/techpapers/papers/why a different
t os/why a differentos.htm, Aug 2000

[14] Giguere, E., "Java 2 Micro Edition," John Wiley & Sons, Inc, New York,
NY 2000

[15] Sun Microsystems, "Java 2 Platform Micro Edition (J2ME) Technology
for Creating Mobile Devices White Paper,"
http://java.sun.com/products/cldc/wp/KVMwp.pdf, May, 2000

[16] Sun Microsystems, "Connected, Limited Device Configuration
Specification Version 1.0,"
http://java.sun.com/aboutJava/communityprocess/final/jsr030/index.html, May,
2000

[17] Sun Microsystems, "Mobile Information Device Profile (JSR-37),"
http://java.sun.com/aboutJava/communityprocess/final/jsr037/index.html, Sep,
2000

[18] Edwards, K., "Core Jini," Prentice-Hall Inc, Upper Saddle River, NJ, 1999

[19] Huang, A. and Ling, B. and Ponnekanti, S., A. Fox, "Pervasive
Computing: What Is It Good For?," Workshop on Mobile Data Management
(MobiDE) in conjunction with ACM MobiCom '99, Seattle, WA, September 1999

[20] Palm, Inc., http://www.palm.com, Jan 2001

[21] Grimm, R. and Anderson, T. and Bershad, B. and Wetherall, D., "A
System Architecture for Pervasive Computing," Proceedings of the 9th ACM
SIGOPSEuropean Workshop, pages 177-182, Kolding, Denmark, September
2000.

[22] Weiser, M., "Some Computer Science Problems in Ubiquitous
Computing," Communications of the ACM, July 1993. (reprinted as "Ubiquitous
Computing". Nikkei Electronics; December 6, 1993; pp. 137-143.)

[23] Richardson, T. and Wood, K. "The RFB Protocol,"
http://www.uk.research.att.com/vnc/rfbproto.pdf, Jul, 1998

[24] Liron, T, VNCj, http://www.amherst.edu/-tliron/vncj/, Jan 2001

[25] Motorola Corp., IDEN J2ME SDK, http://www.motorola.com/IDEN


[26] CommView, TamoSoft, Inc., http://www.tamos.com














BIOGRAPHICAL SKETCH


Samuel W Coons III was born in Atlanta, Georgia in 1961. He attended the

Georgia Institute of Technology and graduated with a Bache lor of Industrial Engineering

in 1984. Mr. Coons then spent 9 years on active duty with the United States Navy as a

Naval Flight Officer. After leaving active duty, Mr. Coons worked as a research engineer

for the Georgia Tech Research Institute. He was also assigned to the Office of Naval

Research as a program manager for several Naval research programs before leaving to

pursue a Master of Engineering degree at the University of Florida. Mr. Coons is married

with 2 children.