virtual thin client: a scalable service discovery approach
TRANSCRIPT
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
iv
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.
v
TABLE OF CONTENTS
page
ACKNOWLEDGMENTS ................................................................................................. iv
LIST OF TABLES ............................................................................................................ vii
LIST OF FIGURES .........................................................................................................viii
ABSTRACT.........................................................................................................................x
INTRODUCTION ...............................................................................................................1
Introduction to Thin-Client Technology......................................................................... 1 Client Server Architecture .......................................................................................... 1 Thin Clients................................................................................................................. 2
Advantages.............................................................................................................. 4 Disadvantages ......................................................................................................... 4
Thin Client Technologies............................................................................................ 5 Network Computer (NC) ........................................................................................ 5 Citrix Independent Computing Architecture (ICA) ................................................ 8 Virtual Network Computing (VNC) ....................................................................... 9
Emergence of Mobile Devices...................................................................................... 15 Mobile Communications........................................................................................... 16 Personal Digital Assistant (PDA) ............................................................................. 16 Personal Communication Services (PCS)................................................................. 17 Mobile Device Operating Systems ........................................................................... 20 Enabling Technologies.............................................................................................. 22
Java 2 Micro Edition (J2ME)................................................................................ 22 Jini......................................................................................................................... 26
PERVASIVE COMPUTING AND MOBILE DEVICES .................................................33
Definitions..................................................................................................................... 33 Deficiencies................................................................................................................... 35 Convergence of New Technologies .............................................................................. 36
VIRTUAL THIN CLIENT APPROACH ..........................................................................37
Problem......................................................................................................................... 37 Uniqueness.................................................................................................................... 38
vi
Architectural Vision...................................................................................................... 38 Design Requirements .................................................................................................... 39 Limitations .................................................................................................................... 40
IMPLEMENTATION........................................................................................................41
Technical Summary...................................................................................................... 41 Client ............................................................................................................................. 41
Class Mapping .......................................................................................................... 42 Flow of Control......................................................................................................... 43
VtcViewer ............................................................................................................. 43 VtcCanvas ............................................................................................................. 44
Event Management ................................................................................................... 46 TEST AND EVALUATION .............................................................................................50
Testing Environment..................................................................................................... 51 Goals of Experiments .................................................................................................... 51
Experiment I.............................................................................................................. 52 Initial screen rendering.......................................................................................... 52 Conclusion ............................................................................................................ 55
Experiment II ............................................................................................................ 55 Data throughput..................................................................................................... 55 Conclusion ............................................................................................................ 57
Experiment III ........................................................................................................... 57 Complexity of input .............................................................................................. 57 Conclusion ............................................................................................................ 60
Experiment IV........................................................................................................... 61 Dynamic pipeline measurement............................................................................ 61 Conclusion ............................................................................................................ 63
Conclusions ................................................................................................................... 63 REFERENCES ..................................................................................................................66
BIOGRAPHICAL SKETCH .............................................................................................68
vii
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. Emulator host environment............................................................................................51
5-2. Comparison of VTC throughput....................................................................................57
5-3. Statistics for “fast” simulation........................................................................................59
5-4. Statistics for “slow” simulation .....................................................................................60
viii
LIST OF FIGURES
Figure Page 1-1. Thin-Client Conceptual View .......................................................................................2
1-2. Thin Client Process........................................................................................................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 Handheld computer .......................................................................................16
1-7. Basic PCS Network Architecture .................................................................................18
1-8. Upgrading 2G Systems to 3G .......................................................................................20
1-9. J2ME software 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 VTC ...........................................................................................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 Rendering Time Results ......................................................................................53
5-4. Initial Rendering Time (802.11) ....................................................................................54
ix
5-5. Counter application for throughput measurement ..........................................................56
5-6. CommView 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 time for “jump” events .........................................................................62
5-10. Average aggregate network delay ...............................................................................62
5-11. Server rendering time ..................................................................................................63
x
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 SEVICE 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
xi
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.
1
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.
2
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.
Applications
Operating Systems
ServerClient
Figure 1-1. Thin-Client Conceptual View [2]
3
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 modern
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
4
this display [1]. Various protocols and methods for encoding the display data are
discussed in a later section.
user logs on for new session
events are passed to server
updated display sent to client
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
5
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
6
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
7
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.
Java App le t s Other A p p l
B r o w s e r G U I
J V MN e t O S
N C O S J a v a O S
N o n S p e c i f i c H W
Java App le t s W i n d o w s
Microsof t Desk top
M S J V M
I n t e l P e n t i u m H W
N C R e f N e t P C
W i n d o w s O S
A p p l .
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
8
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
9
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
10
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
11
Figure 1-4. An X desktop viewed from Microsoft Internet Explorer on a PC [8]
Figure 1-5. A Windows machined viewed from a native X viewer [8]
12
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 l (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
13
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.
14
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
15
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
16
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 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
17
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
tartgets 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 sytems 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.
18
Radio Network
PSTN Mobility
Database
Mobile Switching Center
Base StationController
Base Station
Wireline Transport Network
Mobile Station
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
19
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 macrocells
Medium/ macro and picocells
Small/ zonal picocells
Handset complexity High Low Low
Handset power consumption
High (100-800 mW)
Low (5-10 mW)
Low (5-10 mW)
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.
20
1G analogAMPSTACSNMT
RTMS
2G narrowband, digitalGSM
IS-54/136 TDMAISS-95/cdmaONE
PDC
3G broadband digitalW-CDMAUWC-136cdma2000
2G + or 2.5GVoice and Data
GPRS, HSCDS GSMIS-136A & B TDMA
IS-95C cdmaOne
VoiceVery little data
American roaming
Enhance voiceEuropean roaming
International roamingSome data
VoiceEnhance data
E-mailInternet
Broadband dataVideo
Fast InternetRemote access
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.
21
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.
22
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.
23
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.
Profiles
Configuration
Java VM
Host OS
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].
24
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.
25
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.
J2SE
CDCCLDC
Classes outside J2SE do not use the java.* namespace
Figure 1-10. Relationship between J2ME 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
26
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
27
MID
Native System Software
CLDC
MIDP
OEM-Specific
Classes
MIDPApplications
OEM-Specific
ApplicationsNative
Applications
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
28
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
29
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].
30
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
31
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.
33
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
34
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.
35
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 comp uters, 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.
37
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
38
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.
39
OS
KVM
MIDP
VNC_C
Network
MIDP Device
µJini Proxy
MIDP Service
KVM/JVM
VNC_S
1
2 3
4
MIDP
VNC_S
Other MIDP
Device
HEAP 5
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
40
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.
41
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.
42
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.
43
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.
44
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
45
passes this on to the appropriate case statement for handling. The following figure
illustrates the critical functionality of this method.
while (true)
read server message
create thread
get message type
process message
frame update?
repaint frame
request frame update
yes
no
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
46
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
47
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
waiting
processkey
no event
queuekey
key event
timeout exceeded
time left
done
set alarm
check queue
write event toserver
return element
query
thread boundary
got key
wakeupempty
doneKey Event Producer Thread
Key Event Consumer Thread
Start
Start
Figure 4-3. State Diagram for key event management for the VTC
48
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
49
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.
50
CHAPTER 5 TEST AND EVALUATION
The VTC client code was completed and run utilizing a laptop and IEEE 802.11b
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.
C l i e n t e v e n t
g e n e r a t i o n d e l a yC l i e n t r e q u e s tn e t w o r k d e l a y
S e r v i c e t i m e S e r v e r r e s p o n s en e t w o r k d e l a y
C l i e n t r e n d e r i n g
t i m e
Figure 5-1 Conceptual view of VTC performance pipeline
51
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.11b
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 parame ters 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
52
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
53
Figure 5-2. Initial screen rendering test program
Initial Rendering Time (loopback)
12000130001400015000160001700018000
1 3 5 7 9 11 13 15 17 19
Run
Mili
seco
nds
HextileCoRRERRE
Figure5-3. Initial Rendering Time Results
54
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)
9500
10000
10500
11000
11500
12000
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Run
Mill
isec
on
ds
HextileCoRRERRE
Figure 5-4. Initial Rendering Time (802.11)
The mean time for the Hextile encoding scheme was 10.755 seconds with a
statndard 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.
55
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.
56
Figure 5-5. Counter application for throughput measurement
Figure 5-6. CommView window
The results of the throughput measurements are listed in the following table.
57
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
58
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 = (Time to press * ielement) + 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 Time to 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
ielement 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
59
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.
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
Frequency Chart
mil l iseconds
.000
.014
.029
.043
.057
0
14.25
28.5
42.75
57
1,161.89 2,144.36 3,126.83 4,109.30 5,091.77
1,000 Trials 0 Outliers
Forecast: Total key event generation time
60
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.
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.
Frequency Chart
mil l iseconds
.000
.012
.025
.037
.049
0
12.25
24.5
36.75
49
1,445.12 2,498.18 3,551.23 4,604.29 5,657.34
1,000 Trials 9 Outliers
Forecast: Total time for generation of key event
61
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.
62
=Average Render Time
0
2000
4000
6000
8000
10000
"J" "U" "M" "P" sendM
illis
eco
nd
s
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
150155160165170175180185190
"J" "U" "M" "P" send
Mill
isec
on
ds
Ave network time
Figure 5-10. Average aggregate network delay
63
The last component of the dynamic measurement is the server render time. This
is shown in Figure 5-11.
14.815
15.215.415.615.8
1616.2
Initia
l scr
een
"J"
"U"
"M"
"P"
send
Mill
isec
on
ds
server render time
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.
64
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 impleme ntation will not replace your
desktop or even your laptop but it should allow the Pervasive Computing paradigm to
come one step closer to fruition.
66
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_ref_profile.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
67
[13] Mery, D. “Why is a different operating system needed,” http://www.epocworld.com/techlib/techcomms/techpapers/papers/why_a_different_os/why_a_different_os.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 SIGOPS European 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
68
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.