A new Environment Monitoring Architecture for Adaptive Mobile Applications

anisesecretaryMobile - Wireless

Dec 12, 2013 (3 years and 7 months ago)

118 views

IFSIC

Université de Rennes 1

Campus de Beaulieu

35042 Rennes Cédex

France



Shoshin Research Group

University of Waterloo

Department of Computer Science

200 University Avenue West

Waterloo, Ontario N2L 3G1

Canada









Shoshin

Mobile Computing Proj
ect


A new Environment

Monitoring Architecture

for Adaptive Mobile Applications












Under the supervision of

Professor Jay Black

from University of Waterloo,

Professor Charles Consel

from IFSIC.

By
Guillaume Mocquard

Diplôme d’Ingénieur en
Info
rmatique et Communication


DIIC LSI 2000
Acknowledgments




I would like to thank all the people who made this internship possible.


I would like to thank my supervisor, Professor Jay Black from the University of
Waterloo, for giving me the chance to come

here to work with him, and for making me
feel welcome.


I also would like to thank all the members of the Shoshin Research Group for the great
time I spent with them, the knowledge they shared with me and the fun we had working
together.



3

Abstract


The u
se of mobile wireless devices connected to the Internet is becoming more and more
common. However communication over wireless links can produce dramatic changes of
Quality of Service, with which the traditionally wired
-
oriented Internet deals badly.
Theref
ore software for mobile devices constantly needs to adapt to its environment.

As part of its Mobile Computing Project, the Shoshin Research Group developed the
Communication Manager for Mobile Applications (Comma). This tool helps Adaptive
Client Applicati
ons monitor the environment and, if needed, alter computation and
communication behaviour. The monitoring is handled by a component from Comma, the
Execution Environment Monitor (EEM).

Due to its lack of flexibility, the first version of the EEM did not e
nable us to create
adaptive software for small, resource
-
poor devices such as Personal Digital Assistants
(PDAs). Therefore we decided to redesign the architecture of the EEM to overcome these
problems. We successfully created a new more flexible, dynamic
and distributed EEM,
addressing all the issues which originated from the first version of the EEM.







Résumé


L’utilisation d’appareils mobiles et sans fil connectés à l’Internet devient de plus en plus
courante. Cependant la communication sans fil se c
aratérise par des changements
importants de la Qualité de Service, auxquels l’Internet, traditionnellement cablé, réagit
mal. C’est pourquoi les logiciels mobiles doivent constamment s’adapter à leur
environement.

Dans le cadre du Mobile Computing Project,

le Shoshin Research Group a développé le
Manageur de Communication pour Applications Mobiles (Comma). Cet outil aide les
logiciels clients adaptatifs à monitorer leur environement et, si besoin, à modifier leur
travail et les flux de communication. Le mon
itoring est effectué par un des composants
de Comma, le Moniteur de l’Environment d’Execution (EEM).

A cause de son manque de flexibilité, la première version de l’EEM ne nous a pas permis
de créer du logiciel adaptatif pour des petits appareils limités en

ressources tel que les
assistants et agendas numériques. Nous avons donc décidé de concevoir une nouvelle
architecture pour l’EEM afin de résoudre ces problèmes. Nous avons réussi à développer
un nouvel EEM plus flexible, dynamique et distribué, et avons
ainsi résolu toutes les
difficultés rencontrées avec la première version de l’EEM.



4


Table of Contents


1.

Introduction

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

5

2.

The Existing

Comma System

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

6

2.1.

Adaptivity in the Wireless World
................................
................................
.......

6

2.2.

Presentation of the EEM

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

8

2.2.1.

The Comma Server

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

8

2.2.2.

The Comma Client API

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

9

2.3.

Limitations of the old Comma EEM

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

11

3.

Development of the new Comma System

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

12

3.1.

The New Comma Architecture

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

12

3.1.1.

Instrumentation

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

13

3.1.2.

Source

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

14

3.1.3.

Comma URL

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

14

3.2.

The New Comma Server

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

17

3.2.1.

General Structure of the Comma Server.

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

17

3.2.2.

The Comma Server’s Client Database

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

18

3.2.3.

The Comma Server’s Variable Database

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

20

3.2.4.

The Comma Server’s Instrumentation Database

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

21

3.3.

Instrumentation: Local and Distant

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

22

3.3.1.

Local Instrumentations

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

22

3.3.2.

Distant Inst
rumentations

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

23

3.4.

The New Client API: Comma Services
................................
............................

24

3.4.1.

The Comma Services primary API

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

24

3.4.2.

The Comma Services API for Registered Clients.

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

25

3.4.3.

The Comma Services local Variable Database

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

26

3.4.4.

The Comma Services’ Source Database

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

27

3.4.5.

The Comma Services API for Adaptability

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

29

3.4.6.

The Com
ma Services Recovery System

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

30

4.

Results and future work

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

32

4.1.

Improvements of the new EEM

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

32

4.1.1.

Platform dependency

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

32

4.1.2.

Dynamic

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

32

4.1.3.

Truly distributed

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

33

4.1.4.

Flexible

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

33

4.2.

Projects based on the new Comma System

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

34

4.2.1.

Comma View
er and Manual Instrumentation

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

34

4.2.2.

Palm Instrumentation

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

35

4.2.3.

Adaptive mapping software

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

35

4.3.

Future work

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

37

4.3.1.

SNMP Instrumentation

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

37

4.3.2.

Scheduler in the Comma Server

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

37

4.3.3.

Scenario Player Instrumentation

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

37

4.3.4.

Adaptive HTTP server and proxy

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

37

5.

Conclusion

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

38

Table of Figures
................................
................................
................................
...............

39



5

1.

Introduction


Shoshin is a Research Group in the Computer Science Department of the University
of Waterl
oo, Ontario (Canada). Professors working in the field of Distributed
Systems, as well as their graduate students, constitute its members. The Group was
named after the first distributed system it gave birth to in the 1980s. Shoshin is a
Japanese word for “
beginner’s mind”.


The Shoshin group works on several projects. One of them is Mobile Computing.
This project’s field of interest ranges from wireless networks and mobile IP to
resource
-
limited device’s communication with the Internet. The Mobile Computing

Project is funded by Bell Mobility, and finds its
raison d’être

in the current
Information Technology developments: the use of Internet from personal digital
assistants and cellular phones.



Until very recently, the Internet revolution was mostly concern
ed with the wired
world. Wired technology implies low error rate and fairly stable bandwidth and
connection. The protocols used are tuned to these characteristics. Today’s
technological revolution attempts to efficiently connect the wireless world to the
I
nternet. One problem encountered is that wireless communication’s Quality of
Service can change dramatically in a very short time: bandwidth dropping,
connection loss, error rate and so on. Furthermore small wireless computers have
important resource limit
ations, such as CPU load, power, memory size and user
interface. Therefore the system needs to keep adapting to the current capabilities of
the network and the devices at play.


We chose to define this set of information (network status and device’s avail
able
resources) as the
Execution Environment

of our system. The term “execution”
emphasizes the dynamic nature of this concept: the software must be able to adapt to
its environment at run time. This implies being able to monitor the environment and,
if th
e need arises, being able to alter communication and computation in our system.


To address these issues, the Shoshin Research Group developed the Communication
Manager for Mobile Application (Comma). One of Comma’s modules, the Execution
Environment Monit
or (EEM), is in charge of the monitoring. This paper concerns the
improved version of the EEM.


In the first part we will talk about the first version of Comma. We will describe the
EEM and explain the limitations of that system. Then we will present the l
atest
development of the Comma platform, the new abstractions we used and the
architecture that ensued, as well as the improved services offered by the platform and
its new API. Finally we will discuss the results of that development, the problems of
the o
ld Comma architecture we successfully addressed in the new one, the projects
based on our new platform, and what we hope to achieve in the near future.


6

2.

The Existing Comma System


The Comma platform is a tool to support Adaptive Client Applications. It con
sists of
a monitoring module, the Execution Environment Monitor (EEM), and a
communication stream modifier, the Service Proxy (SP). The SP is still in
development at this time. This paper exclusively focuses on the monitoring function
of Comma.

We will st
art with an introduction to dynamic adaptivity in the wireless world. Then
we will present the EEM’s architecture, as well as the services provided by its API.
Finally, we will discuss the limitations of the first version of the Comma EEM.


2.1.

Adaptivity in
the Wireless World


We will first introduce some concepts about the wireless world that will make it
easier to understand what we want to achieve with the Comma platform.





Figure 1.

The wireless device connection to the Internet.


A mo
bile wireless device accesses the Internet through a wireless connection to a
base station. The base station is the gateway to the wired Internet. It is in charge
of the wireless communication within one cell. Every other cell is managed by
another such ba
se station. Note that the shifting from one cell to a new one might
cause huge changes in Quality of Service, as well as in the path of communication
with other machines.



7

A mobile wireless device usually communicates either with its Home agent (its
office

or home desktop) or with some Internet application server. In both cases,
the communication stream will travel from there throughout the wired Internet,
until it gets to base station and then reaches the mobile device. Most of this
communication is ruled
by “wired
-
oriented” protocols such as TCP. These
protocols, which are tuned to the wired world characteristics, respond badly to the
behaviors encountered in the wireless world.


In general wired machines are used to dealing with other wired and powerful
m
achines, not with wireless, resource
-
limited mobile devices. Modifying the
current Internet ways would mean completely re
-
building most of the Internet. A
cheaper solution is to use proxies. Instead of talking directly to a mobile device, a
server can talk

to its proxy, which is running in the wired Internet and if possible
close to the base station. This proxy could alter communication protocols and
streams, and make the necessary adjustments to improve communication between
wired and wireless. This whole
scheme would be transparent from the server’s
point of view, which wouldn’t see the difference between a wired and a wireless
client.


Using a proxy implies some kind of cooperation between the wireless device and
its proxy counterpart. Indeed some of the
computation involved should be able to
“migrate” from one to the other, to adapt to the current environment’s capabilities.
For instance, we can imagine a limited mobile device to check the mailbox from
some Mail server in the Internet. If the device canno
t display pictures, the proxy
could filter them. If the screen only displays black and white, the proxy could
convert the color ones. If the bandwidth is very low, we might want to receive
only the headers of the messages. Other examples come to mind: a pr
oxy could
drop frames from an MPEG stream to follow a bandwidth change, and so on.


The Execution Environment Monitor, that we present in the next section, gives us
the tool to monitor the network, the base station, the mobile device and possibly
other mac
hines. All these machines may consider adapting when they receive the
information gathered by the EEM.


8


2.2.

Presentation of the EEM


The Execution Environment Monitor, as it was designed in the first version of
Comma, follows a Client/Server architecture. Eve
ry machine in the network can
provide information about its environment by running a Comma Server. An
Adaptive Client Application acquires this information through the Comma Client
API.



Comma
Server
SNMP
Local
Variables
Adaptive
Client
Application
Comma Client API
Adaptive
Client
Application
Comma Client API
Adaptive
Client
Application
Comma Client API


Figure 2.

Architecture of the first version of
the EEM.



2.2.1.

The Comma Server


The Comma Server is the heart of the EEM. It was developed in C for Linux and
AIX. Its job consists of gathering information about its environment and offering
it to remote client applications.


This information is structured
in Comma Variables. The server provides two sets
of Comma Variables:



SNMP, the various SNMP variables.



The Local Variables, anything that is likely to be of interest that is not part of
SNMP.



9

These Comma Variables are listed in a header file known to bot
h the Server and
the Client. Each Variable are designated by a number and is of one of the three
following types: long, double or string.


The Comma Server features two ways to request information:



Ask for the value of a particular Comma Variable, and rece
ive the value
immediately.



Register interest in a particular Comma Variable, and receive value updates
periodically every 5 seconds or so.


The Comma Server can serve several Clients simultaneously. Each Client
connects to the Server through a socket. Once

it is connected, the Client can
request information from the Server until it disconnects. The protocol used
between Client and Server is ASCII based, which means that a client can access
the Comma Server via Telnet. We will describe this protocol later on
.


2.2.2.

The Comma Client API


The Comma Client API was also developed in C for Linux and AIX. It provides a
layer between an Adaptive Client Application and the network link to the Comma
Server.


Adaptive
Client
Application
Comma
Server
Protected
Memory
Space
Communication
System
access
update
Comma Client API
Callback
System
callback


Figure 3.

The former EEM’s Comma Client API
architecture.


When the API initializes, a thread is created to handle communication with the
Comma Server. This thread receives the values of the requested Comma Variables
from the Server, and updates a protected memory space. The Adaptive Client
Applicat
ion can access that piece of memory as needed to get the updated
information. The API also features a callback system: when a new value is
received the Client can be informed of a change by being “called back”.


We present here the Comma Client API and Cli
ent/Server protocol used between
the API and the Comma Server:


10




Init
:

initializes the communication thread and the protected memory
space.



SetCallback
:

sets the callback function to be called when an update is
received.



GetValueOnce
:

requests the value
of a Comma Variable from the Comma
Server.



VarRegister
:

requests to receive periodic updates of a Comma Variable. We
also say: “register interest in a Comma Variable”.



VarDeregister
:

deregisters interest in a Comma Variable.



GetValue
:

requests the value

of a Comma Variable from the protected
memory space.



HasChanged
:

inquires if the value of a Comma Variable from the protected
memory space has changed.



Figure 4.

The former EEM’s Comma Client API.





Client registration is made by connecting to the Server.



Client

deregistration happens when EOF is received.




Get a value once:

GET

var:<
variable number
> (index:<
variable index
>)



Register interest:

REG

var:<
variable number
> (index:<
variable index
>)
(range:<
range of values we are interested in
>)



Deregister interest:

DEL

var:<
variable number
> (index:<
variable index
>)




Acknowledge registration:

211

var:<
variable number
> (index:<
variable index
>)



Registration failure:

511

<
error message
>



Get once result:

212

var:<
variable number
> (index:<
variable index
>) value:<
value
>



Ge
t once failure:

512

<
error message
>



Acknowledge deregistration:

213

var:<
variable number
> (index:<
variable index
>)



Deregistration failure:

513

<
error message
>



Periodic update:

214

var:<
variable number
> (index:<
variable index
>) value:<
value
>



Figure 5.

The former EE
M’s Comma Communication Protocol.


11

2.3.

Limitations of the old Comma EEM


The Execution Environment Monitor, as it was designed in the first version of the
Comma System, has serious limitations. The most significant criticism was its
lack of flexibility. Indeed
the system was both difficult to expand and not very
robust. Furthermore it was not compatible with our target devices: palmtop
computers and PDAs. We describe here in more details the four main reasons of
the development of a new EEM system.


First, both
the Comma Server and the Comma Client API are platform dependent.
They were developed in C for Linux and AIX. It is important to note that they
make use of sockets and threads, two platform
-
specific technologies. It would be
non
-
trivial to port the EEM to
Windows NT, and unthinkable to port the current
EEM’s architecture to Windows CE or PalmOS.


Second, the set of information provided by the EEM is fixed at compile time,
consisting of SNMP and the Local Variables. To add a new Variable, both Server
and Cli
ent must be recompiled. We would like to be able to dynamically add new
Variables to the set of information available, without having to shutdown and
restart the Comma Server.


Third, the EEM is a very centralized system. Everything depends on the Comma
Se
rver. If the Server crashes, there is no hope of recovery for any of its Clients.
Indeed in that case we have to restart the Server, reconnect every client and
register interest again in all the Comma Variables for each Client. This is a very
fragile distr
ibuted system and we want to create a more flexible architecture to
enable some recovery schemes.


The fourth point concerns the target devices of the Mobile Computing project. We
want to improve mobile applications on small, possibly wireless, resource
-
po
or
devices. For example if we want to offer information about the resource status of
some PDA to its home agent, or to some kind of application server in the Internet,
then we have to run a Comma Server on the device. Even if we could easily port
the soft
ware to our target PDA, this kind of machine does not have the resources
needed to run a full Comma Server in the background.


This last problem triggered our study for a development of a new EEM. We were
trying to find a way to run a Comma Server on a Pa
lm Pilot, but the limited
number of sockets the device permitted (4) rendered this infeasible. At that point
we started re
-
thinking the whole Comma EEM architecture, which eventually led
to the new development described in the next section.


1
2

3.

Development of

the new Comma System


This latest development of the Comma platform was born out of our desire to
overcome the limitations of the previous version of the Execution Environment
Monitor. We present here the architecture we designed, the new abstractions we

created, and the new schemes and entities necessary, to provide the best service to
Adaptive Client Applications.


3.1.

The New Comma Architecture


The new architecture of the Execution Environment Monitor is more complex
than the previous one. Figure 6 gives
an overall view of the architecture. We will
describe in more details each module and interface in the following sections.



Local Server
Source
Distant
Source
Comma
Server
Instrumentation
interface
Instrumentation
interface
Adaptive Client
Application
Comma
Services API
Source
interface
Direct
Instrumentation
Source
socket
communication
Local Java
Instrumentation
Local Native
Instrumentation
JNI
Java Stub
Distant
I
nstrumentation
Stub
Distant
I
nstrumentation
(remote process)
socket
communication
Distant
I
nstrumentation
Stub
Local Java
Instrumentation
Local Native
Instrumentation
JNI
Java Stub
Instrumentation
interface
Local Java
Instrumentation
Local Native
Instrumentation
JNI
Java Stub
Distant
I
nstrumentation
Stub
socket
communication
socket
communication


Figure 6.

The new EEM’s Architecture.




13

3.1.1.

Instrumentation


The Comma Server was the keystone of the old Execution

Environment Monitor.
We therefore decided to redesign it first. The old Comma Server had two distinct
jobs: gathering information about the environment and share this data with its
Clients according to the Client’s needs. We decided to split up the Comma
Server
along these functional lines, and ended up with two separate entities: a Data
-
Gathering unit and a Data
-
Managing module.


Each Data
-
Gathering unit provides a set of Comma Variables. The Data
-
Managing module can handle several Data
-
Gathering units, w
hich all share the
same interface. We chose the name Instrumentation for this interface to convey
the meaning that this module does the computation, the actual measure, of the
Variable we are interested in. We keep the name Comma Server for the Data
-
Managi
ng module, with the idea that the data is managed to be
served

to the
Adaptive Client Applications.


Client
API
Comma Server
(data-managing)
Instrumentation
interface
Adaptive Client
Application
socket
communication
Instrumentation 1
(data-gathering)
Instrumentation 2
(data-gathering)


Figure 7.

The new Comma Server.


This whole scheme is both flexible and dynamic as it enables us to plug and
unplug Instrumentations in
to the Comma Server whenever we need or cease to
need the Variables they provide.


We chose to make the Instrumentation focus on the computation of the Comma
Variables it provides. The resulting interface only features two methods that we
present here:





L
ist
:

returns the list of Comma Variables provided by the Instrumentation.



Update
:

asks an update of a Comma Variable.



Figure 8.

The Instrumentation interface.



14

3.1.2.

Source


The Instrumentation is limited in terms of services offered because it is focused
on the compu
tation of Comma Variables, not on their delivery to a Client. In our
search for abstractions, we came up with a new richer interface to feature all the
services we want to offer. We called it the Source interface to emphasize on the
fact that although a So
urce provides information, this data does not necessarily
originate from it.


The Source interface extends the Instrumentation interface with Variable
Registration facilities. When an Instrumentation only provides a Variable update
on a one
-
time basis, a S
ource will send updates on a periodic basis, or if the value
has changed, or if the value falls into a specified range. We present here the
Source interface:






List
:

returns the list of Comma Variables provided by the Instrumentation.



Update
:

asks an up
date of a Comma Variable.



Reg
:

registers interest in a Comma Variable for a certain range of values,
and expects to receive periodic and/or on
-
change updates.



Dereg
:

deregisters interest in a Comma Variable.



Figure 9.

The Source interface.



This interface match
es the point of view Adaptive Client Applications have of the
Comma Server. Furthermore, since a Source can be viewed as an Instrumentation,
we can now serialize two Comma Servers by making one the Instrumentation of
the other. This enables us to design ne
w schemes of cooperation of Servers and
improve the overall connectivity of the system.



3.1.3.

Comma URL


This whole new architecture generated new issues. The Adaptive Client
Application now has several ways to get to a Comma Variable: directly at its
Instrume
ntation, from a Source serving that Instrumentation, or even from another
Source connected to the previous one and eventually the final Instrumentation.


The data structure representing all the Comma Variables available to an Adaptive
Client Application c
an be seen as a set of trees. A Source is the root of a tree: it
contains Instrumentations. An Instrumentation is a node, something of a directory

15

in a file system, and it contains Instrumentations and Comma Variables. And a
Comma Variable is a leaf, like
a file in a file system.




Adaptive Client
Application
Comma
Source
Comma
Source ...
Comma
Instrumentation
Comma
Instrumentation
Comma
Instrumentation
Comma
Variable
Comma
Variable
Comma
Variable
Comma
Variable
Comma
Variable
Client
API

Figure 10.

The Comma Variable Data Structure.



This data structure clearly resembles a file system. We therefore chose a URL
representation of the path of a Comma Variable in that system, as follows:

eem://ins
tr1/…/instrN/var
.


The Adaptive Client Application wishing to get to that Variable will ask
instr1

for

eem://instr2/…/instrN/var
.

The Instrumentation
instr1

will ask
instr2

for
eem://instr3/…/instrN/var
. And so on until the last hop,
instrN
, which
will pro
vide the requested variable
var
.



This
file system
-
like

representation gives us an easy way to structure the data
provided by the Execution Environment Monitor. It enables us to reflect the
connections between the various entities of the system, as well a
s inside these
entities. Even within an Instrumentation, the Comma Variables can be ordered
into sub
-
Instrumentations according to some pertinent ordering. For example an
Instrumentation (LocalSystem) could be plugged into a Comma Server
(styx:1400). This
Instrumentation provides information about the local host. Some
of this information concerns the CPU: the LocalSystem Instrumentation therefore
features a CPU sub
-
Instrumentation. This sub
-
Instrumentation provides two
Comma Variables: serialNumber (the ser
ial number of the CPU) and averageLoad
(the average load of the CPU).



16

Client
styx:1400
(Comma Server)
LocalSystem
(Instrumentation)
CPU
(Instrumentation)
averageLoad
(Variable)
serialNumber
(Variable)
eem://styx:1400/LocalSystem/CPU/averageLoad


Figure 11.

Example of Comma URL.



Some Comma Variables are constant, while others have to be computed. In the
first version of the EEM, some Variables were indexed.
This was useful for some
SNMP variables. We decided to pursue this idea that Comma Variables could be
viewed as functions, and therefore should have parameters. This is how we
included the parameters in the Comma URL representation:


eem://instr1/…/instrN/
var/param1/…/paramN


It is interesting to note that Source, Instrumentation, Variable and parameters all
seem to be the same in the Comma URL scheme. Each Instrumentation only
knows the type of the next element in the Comma URL. Indeed an
Instrumentation i
n the middle of the list just passes on the Client’s request to the
next Instrumentation: it does not need to know anything about the rest of the
URL. The last Instrumentation is an exception: it knows that the next element is a
Variable and the following

ones are parameters because it really needs them to
compute the Comma Variable’s value.


The final feature of the Comma URL system concerns the options. The Comma
URL represents a path to a Comma Variable, it can also store extra information
such as valu
e and registration options. For example Variable registration
information for a Source, such as range of values you are interested in and
updates options, will be conveyed in the URL as options:


eem://instr1/…/instrN/var/…/paramN?opt1=<val1>?…?opt2=<valN>



17

3.2.

The New Comma Server


3.2.1.

General Structure of the Comma Server.


The new Comma Server is still a major component of the Execution Environment
Monitor. Now that it is separated from the Instrumentation, it does not have to be
developed in a system oriented
programming language such as C. We chose Java
for portability and the ease with which network software can be developed.



Client
Database
(CDB)
Instrumentation
Database
(IDB)
Variable
Database
(VDB)
Client
Registration
Update (Var)
Accept (Client)
Update (Var,
period)
New
Client
Client
1
Client
2
Instrumentation 1
Instrumentation 2
Comma Server


Figure 12.

Architecture of the new Comma Server.



The Server is composed of four objects:



a Client Registration m
odule constitutes the gateway the remote Clients use to
connect to the Server.



a Client Database (CDB) contains a Client
-
handler for each remote Client
connected to the Server.



a Variable Database (VDB) keeps track of all the Comma Variables the
Server’s C
lients are interested in.



an Instrumentation Database (IDB) gives access to the Instrumentations
providing the Comma Variables the Clients need.


Each remote Client’s request is processed by a Client
-
handler from the CDB. This
Client
-
handler asks the VDB f
or the relevant Comma Variable value. The VDB is
kept up to date by requesting new updates from the IDB, which conveys each
request to the appropriate Instrumentation.


18

3.2.2.

The Comma Server’s Client Database


To get access to the Comma Server’s resources, a r
emote Client must connect
through the Client Registration module. This object runs its own thread to listen
for new connections on a socket.


Once the connection is established, the Client Registration module gives the
resulting socket to the Client Databa
se (CDB). That socket acts as an identifier of
the remote Client for the Comma Server. The CDB creates a Client
-
handler to
take care of the remote Client’s requests.



Net Access
Distant Source
Protocol
socket
process
send
Variable Database
(ChVDB)
Variable 1
(URL, updating thread)
Variable 2
(URL, updating thread)
add(Var)
remove(Var)
send(update)
Client - handler 1
...
Client - handler 2
socket
Client
1
Client
2
Variable
Database
(VDB)
Update (Var,period)
Client Database (CDB)

Figure 13.

Architecture of the new Comma Server’s Client Database.




The Client
-
handler contains a Client/Server protocol handler and a Variable
Database. The protocol handler parses the remote Client’s messages, processes its
requests and formats the messages sent back. We present here the Distant Source
communication prot
ocol, which is used between the Comma Server and its
Clients:




19




LIST

eem://<
instrumentation
>

OK:

216

list eem:<
instrumentation
> | eem://

(
217

<
CommaURL with
?type=<
type
> >)*

218

end

FAIL:

516

eem://<
instrumentation
>?error=<
error msg
>




GET

<
CommaUR
L
>

required options: none

OK:

212

<
CommaURL

with

?value=<
value
> >

FAIL:

512

<
CommaURL
>?error=<
error

msg
>




REG

<
CommaURL
>

required options: none

possible options: periodic (default=5000), onchange (default=0), range
(default=always)

OK:

211

<
CommaU
RL
>

FAIL:

511

<
CommaURL
>?error=<
error msg
>

PERIODIC UPDATE:

214

<
CommaURL with

?value=<
value
> >

ONCHANGE UPDATE:

215

<
CommaURL with

?value=<
value
> >




DEREG

<
CommaURL
>

required options: none

OK:

213

<
CommaURL
>

FAIL:

513

<
CommaURL
>?error=<
error m
sg
>




Redirect command:

300

eem://<new
Source
>/<
instrumentation relative ID
>




Unknown command:

400

unknown command:<
command line
>



Figure 14.

The Distant Source Communication Protocol.



20

Three options are used for registering interest in a Variable in the Distant

Source
protocol:



periodic
:

how often do you want the Source to send an update (in
milliseconds).



onchange
:

how often do you want the Source to check if the value of the
Variable has changed (in milliseconds).



range
:

the range of values within which you
are interested by the
Variable’s value.


We present here the Comma Range system:




Range

= <
Operator
> ( + <
Lower

Bound
> ( + <
Upper

Bound
> ) )




Operator

= always | eq | neq | gt | gte | lt | lte | in | out



Examples of ranges are: "
always
", "
eq 3.4
" (

= 3.4), "
lt hello
" (< hello),

"
in
-
78 123
" ( >=
-
78 and <= 123).



Figure 15.

The new Comma Range system.




The Client
-
handler contains its own Variable Database (ChVDB). Each Variable
object from the ChVDB represents a Comma Variable registered by the remote
Clie
nt, and runs its own thread which is responsible for sending periodic and on
-
change updates at the proper time. Obviously this design might use a great
amount of threads (one per registered variable), creating a costly overhead. We
plan to improve the perf
ormance in the future by introducing a scheduling system.



3.2.3.

The Comma Server’s Variable Database


In addition to the Client
-
handler Variable Database (ChVDB), the Comma Server
maintains a Variable Database (VDB). When a Variable from the ChVDB
requires an
update, it requests the latest value from the VDB.


The VDB keeps track of all the Comma Variables accessed by the Server’s
Clients, as well as the time of the last update. When it is asked to give the latest
value of a Variable, it must decide whether t
he current value it holds is
sufficiently up to date. If it is too old, then the VDB requests an update from the
Instrumentation Database.



21

A heuristic is used to decide if a value is “fresh.” The Variable object from the
ChVDB asking for its latest value
must also tell the VDB its probable updating
period (how often it intends to ask for updates). If the value held in the VDB was
last updated within one tenth of that period, then it is considered “fresh.”


This whole scheme is used so as to limit the loa
d on the Instrumentations.



3.2.4.

The Comma Server’s Instrumentation Database


The Comma Server manages its Clients as well as the Instrumentations providing
the Comma Variables the Clients are interested in. The Instrumentation Database
(IDB) contains all the
Instrumentations plugged into the Comma Server.


When the Comma Server’s Variable Database requires an update from a specific
Instrumentation, it requests it from the IDB. The IDB in turn will convey that
request to the appropriate Instrumentation.


Every
Instrumentation has an unique ID. Each Comma Variable it provides also
features that ID as the first element of its Comma URL. The Instrumentation
Database only needs to look at this first element of the URL to know which
Instrumentation should answer the

request.



22

3.3.

Instrumentation: Local and Distant


The Comma Server obtains information from Instrumentations plugged into its
Instrumentation Database. These Instrumentations share the same interface, but
they can differ tremendously from one another. We can

order them into three
families: local Java, local native and distant.


3.3.1.

Local Instrumentations


Local Instrumentations are either Java or native Instrumentations.


1.

The local Java Instrumentation is a collection of Java classes that can compute
Comma Variab
les.


Comma
Server
Instrumentation
Database
Local Java
Instrumentation
...


Figure 16.

The Local Java Instrumentation.


2.

The local native Instrumentation needs a Java stub that calls native code
through the Java Native Interface. The native code takes care of the Comma
Variable computing. This kind of Instr
umentation can be very useful to get
system and network data, that is usually coded in a low level native
programming language.


Comma
Server
Instrumentation
Database
...
Local Native Instrumentation
Java
Stub
JNI
Native
Instrumentation


Figure 17.

The Local Native Instrumentation.



23

3.3.2.

Distant Instrumentations


The distant Instrumentation needs a
Java stub that connects to some remote
process (Java or native), which will handle the computing of Comma Variables.


This kind of Instrumentation is very useful to get information from small,
resource poor devices, because it does not requires substantia
l resources to run
such a small Instrumentation server.


Comma
Server
Instrumentation
Database
Java
Stub
...
Distant
Instrumentation
(Java or Native)


Figure 18.

The Distant Instrumentation.



Such an Instrumentation can be connected either to a Comma Server or directly to
an Adaptive Client Application. It features a listening s
ocket, which once
connected to a Client, sends a redirect message to indicate where the Client can
get access to the Comma Variable the distant Instrumentation provides. This way,
if a Comma Server crashes, the distant Instrumentation can ask to be served
by
another Comma Server, and properly redirect all its Clients.


Comma
Server
Instrumentation
Database
Java
Stub
...
Distant
Instrumentation
Serving port
Redirect port
Adaptive Client
Application
Client
Database
update
get
connect (1)
redirect to Comma Server
connect (2)
register


Figure 19.

The Redirect System of the Distant Instrumentation.


24

3.4.

The New Client API: Comma Services


The Comma Services replaces the Comma Client API in the old Execution
Env
ironment Monitor. It features improved functionalities such as multiple
Source management and multiple Client Registration. We present here the new
API as well as the internal architecture of the Comma Services.



3.4.1.

The Comma Services primary API

The purpose

of the Comma EEM is to provide information to an Adaptive Client
Application about its environment. To benefit from the EEM, the Client must
instantiate a Comma Services object. Then the Client can get a Comma Variable’s
value on a one
-
time basis (
getOnce
), or register interest in the Comma Variable
(
varReg
) to keep the Comma Services’ local Variable Database updated. In the
later case, the Client can get the information directly from the local Variable
Database (
get
).



Adaptive Client
Application
Source
Database
Local
Variable
Database
Comma
Server
Comma
Server
API
Comma Services


Figure 20.

The C
omma Services internal architecture.



When a Client registers interest in a Comma Variable, it should tell the Comma
Services the range of values it is interested in (Comma Range), how often it wants
the local value to be updated (periodic update) and how

often it wants the Source
of the Variable to check if the value has changed (on change
-
update).




25




GetOnce
:

simply fetches the latest value of a Comma Variable at its Source.




Get
:

returns the value of a Comma Variable from the local Variable
Database.




VarReg
:

registers a Comma Variable in the local Variable Database, as
well as at its Source to arrange the local value’s update.




VarDereg
:

deregisters a Comma Variable at its Source, and removes its entry
in the local Variable Database.



Figure 21.

The Comma Servic
es primary API.




3.4.2.

The Comma Services API for Registered Clients.


We designed the Comma Services to enable independent access to its facilities by
several components from the Adaptive Client Application. We call these
components Client objects.


The key
to this part of the Comma Services API is the Client registration. A
Variable may be registered only once by the Adaptive Client Application, but
several Client objects can “
clientRegister
” interest in a Comma Variable on
top of the regular “
varRegistratio
n
”. The Comma Services will reflect all the
Client registrations of a Comma Variable by merging all the parameters (range,
update options), and make a multiplexed registration request to the Source of the
Variable. When the Comma Services receives updates
from the Source, it will
inform the Client objects according to their registration parameters.


Each Client object is known to the Comma Services, which enables us to bring
two new services:



Status of the local value from the point of view of a particular
Client object:
has it changed since the Client last inquired.



Callback facilities for both periodic updates and on
-
change updates: the Client
can designate a Listener object to process such callbacks.



26


We present here the Comma Services API for Registere
d Clients:





ClientReg
:

registers interest as a Client in a registered Comma
Variable.




ClientDereg
:

deregisters interest as a Client in a registered
Comma Variable.




HasChanged
:

tells a registered Client if the value of a Comma
Variable has changed since
it last inquired about it.





AddPeriodicListener
:

sets the object the Comma Services will callback
when receiving a periodic update.




AddChangeListener
:

sets the object the Comma Services will callback
when receiving an on
-
change update.



Figure 22.

The Comma Servic
es API for Registered Clients.



There are some security features involved in this part of the Comma Services
API: if you try to deregister a Variable (
varDereg
) and some Client objects that
registered interest in it have not deregistered, an exception wil
l be thrown and the
deregistration will not be carried out. This is to ensure that a Client object will not
deregister a Variable when another object still needs it.


Note that the Callback facilities might create deadlocks in the system in the case
of re
-
entrant code, such as using the Comma Services API from the callback
method.


3.4.3.

The Comma Services local Variable Database


The Comma Services’ local Variable Database manages the registered Comma
Variables and the registered Client objects.


A hash table s
tores all the Variable objects. Each Variable object owns a list of
Client objects that registered interest in the Comma Variable. It also keeps a
“default Client” to store the parameters of the first Variable registration (
varReg
),
the one that happened b
efore any of the Client object registration. Finally the
Variable object features the registration parameters of the current registration, that
is to say the last registration requested at the Source of the Comma Variable.



27

...
Source
Database
Client
Object 1
Client
Object 2
Local Variable Database
API
Comma Services
Adaptive
Client
Application
Variable
def ault
client
client 1
client 2
current
registration
parameters
varReg
clientReg
clientReg
register


Figure 23.

T
he Comma Services Client Registration.



The registration parameters (range and update options) are the result of the
merging of the parameters of all the Clients (objects and default). If a new Client
registration or deregistration occurs, these parameter
s will be computed again. If
they differ from the former ones, a new registration request reflecting these
changes is sent to the Source of the Comma Variable.


When an update is received from the Source of the Comma Variable, the
following happens:



The lo
cal value is updated.



If the value differs from the former one, the “has
-
changed flags” are reset.



If it is an on
-
change update, the value is in range and the Client has a change
Listener, then we execute the callback method of the change Listener.



If it
is a periodic update, the value is in range, the Client has a periodic
Listener and it is time for a Client to be informed, then we execute the
callback method of the periodic Listener.



3.4.4.

The Comma Services’ Source Database


All the requests of the Adapti
ve Client Application go through the API, to the
local Variable database and then to the Source Database. From the name of the
Comma Variable requested, which is represented by a Comma URL, the Source
Database can determine which of the current Sources it
holds should execute that
request.


The real work of the Source Database occurs when the requested Source is not in
the Database. In that case, the Source Database has to make contact with the
Source of the Comma Variable, and create the appropriate entry
in its Database to
be able to use it.


28


The problem is that we do not know what kind of Source we will connect to. We
are not even sure it is not a simple Instrumentation without the richer Source
functionalities. When the Source Database connects to the S
ource, it receives a
message telling it what Source or Instrumentation version it is. According to that
version, the Source Database will instantiate the right stub to work with such an
entity


If it is a full Comma Server, then the Source Database creates

a Distant Source
stub. If it is a Distant Instrumentation, then the Source Database has two
possibilities:



Either it starts a small local Comma Server stub that will handle the data
-
management only for that Instrumentation and for the benefit of this Com
ma
Services alone,



Or it only provides the Instrumentation functionality through an
“Instrumentation
-
to
-
Source” stub, as a limited Source. In that case, variable
registration and deregistration will not be provided.



Source
Database
Comma
Server
Distant
Instrumentation
Distant
Instrumentation
Distant Source Stub
(Get, Reg, Dereg)
local Comma Server
(Get, Reg, Dereg)
Direct Instrumentation
Source stub
(Get)
Get, Reg, Dereg
Get
Get
...


Figure 24.

The Sou
rce Database possible remote Source stubs.



As we explained in section 3.3.2, some Instrumentations will send a redirect
message when they are contacted. This message indicates which Source serves the
Instrumentation, and what the Instrumentation ID is fr
om the Source’s point of
view. The Source Database therefore needs to connect to this new Source and
repeat the process described above, that is get the Source’s version and instantiate
the correct stub. Furthermore, the Source Database needs to keep track

of which
Source serves which Instrumentation to be able to modify the URL of the
requested Comma Variables accordingly.



29

Comma Server
(styx:1400)
Instrumentation
(shosh8:1500)
Source
Database
Redirect port: 1500
Serving port: 1501
Instrumentation
Database
shosh8:1501
Distant Source
styx:1400
Conversion table:
shosh8:1500
<->
styx:1400/shosh8:1501
The Comma Server manages
the Comma Variables f rom the
Instrumentation
1-
connect
2-
redirect to
styx:1400/shosh8:1501
3-
connect
4-
version
5-
Get, Reg, ...

Figure 25.

Example of connection to remote Source with redirection.




3.4.5.

The Comma Services API for Adaptability


The
Comma Services will be used by Adaptive Client Applications. It appears to
be useful for the Comma Services to also be in some ways adaptive. The adaptive
scheme we designed is somewhat primitive. It all takes place in the Source
Database.


We presented in

the previous section the three stubs available at this time to
connect to a Comma Variables’ Source. These stubs do not all require the same
amount of resources. For example the Distant Source stub, used to connect to a
Comma Server, only needs a socket a
nd a thread to operate. The local Comma
Server is a far more demanding stub: it needs a thread for each Comma Variable
registered as well as a socket to the remote Instrumentation. Finally the direct
connection to an Instrumentation requires a socket but n
o thread; however it does
not offer much in terms of functionality.



The Comma Services API for Adaptability gives the Adaptive Client Application
the possibility to forbid the use of some of the three stubs used to get to the
Source of the information.




30




AcceptDistantInstrumentation
:

allows or forbid direct connection to an
Instrumentation.




AcceptDistantServer
:

allows or forbid connection to a Distant
Source, such as a Comma Server.




AcceptLocalServer
:

allows or forbid the creation of a local mini
-
Comm
a
Server to manage the data coming from a Distant
Instrumentation.



Figure 26.

The Comma Services API for Adaptability.





3.4.6.

The Comma Services Recovery System


If at some point a Source becomes unavailable, all the entries in the local Variable
Database representing

Comma Variables from that Source will become
unavailable. But the registration information as well as the list of registered
Clients is kept safe, until the Source is available again. To reconnect to this
Source the Adaptive Client Application should reg
ister interest in one of the
unavailable Variables again. The Source Database will then try to make contact
with the Source. If the Source is back on line, all its Variables will become
available again.




Comma Services
Adaptive
Client
Application
API
Variable DB
Source
DB
Source 1
(v1, v2, v3)
Source
stub 1
Source 2
(v4)
Source
stub 2
v1
v4
v2
v3
varReg
The Adaptive Client Application registered interest in 4 Comma
Variables: v1, v2 and v3 from Source 1, and v4 from Source 2.




31

Comma Services
Adaptive
Client
Application
API
Variable DB
Source
DB
Source 1
(v1, v2, v3)
Source
stub 1
Source 2
(v4)
Source
stub 2
v1
v4
v2
v3
Get
If Source 1 becomes unavailable, all the registered Comma
Variables from Source 1 become unavailable as well. If the
Adaptive Client tries to access v1, it will be told that the variable
is not available at this time.



Comma Services
Adaptive
Client
Application
API
Variable DB
Source
DB
Source 1
(v1, v2, v3)
Source
stub 1
Source 2
(v4)
Source
stub 2
v1
v4
v2
v3
varReg
If Source 1 is back online, the Adaptive Client Application only
needs to re-register interest in one of Source 1's variables, v1
for instance. If reconnection is successful, all the variables
previously registered become available again.



Figure 27.

The Comma Services Recovery System.


32


4.

Results and future work


This new architecture of the Execution Environment Monitor took five months to
develop: approximately one month to study the former version of the EEM
, two
months of design and two months of coding and testing.


As we explained in section 2.3, the reasons for this new development of the Comma
platform were to overcome the limitations of the former EEM. We present here the
improvements made in the new EE
M, the various adaptive applications using our
software and our plans for future enhancement


4.1.

Improvements of the new EEM


4.1.1.

Platform dependency


The old Execution Environment Monitor was developed for Linux and AIX. It
was designed to be able to get system
and network information, which implied the
C language. Indeed, to have access to that kind of data, you need to use an OS
level language. The drawback is that it then becomes very difficult to port such
software to another platform.


We believe we solved t
hat problem in our new EEM by splitting the data
-
gathering part from the data
-
managing part. On the one hand, the data
-
managing
is handled by the Comma Server; we want to be able to run that piece of software
in as many places as possible: this is one of t
he reasons why we used Java. On the
other hand, the data
-
gathering unit, the Instrumentation, is inevitably platform
specific. For example the code to get CPU average load on a Palm Pilot is not the
same as on a Linux workstation. Therefore these two Instr
umentations have to be
different ones and coded differently.


The Instrumentation interface allows the creation of Java stubs communicating
with Java and/or native code, locally or throughout the network. This scheme is
flexible enough to enable monitorin
g anywhere.



4.1.2.

Dynamic


The set of Variables provided by the old EEM was completely static. Adding a
new Variable meant modifying the source code and recompiling the whole
system.



33

Here again, the separation of the Instrumentations from the Comma Server mad
e
the difference. If we want to add a new set of Comma Variables, we just create a
new Instrumentation. If we want to modify an existing Instrumentation, we just
have to disconnect the old one from the Comma Server and connect the new one.



4.1.3.

Truly distribu
ted


The Comma Server was the heart of the former Execution Environment Monitor.
This made the whole system very fragile: nothing would survive a crash of the
Comma Server.


The Comma Server remains a key element of the new EEM. However the
extended connec
tivity of the new system prevents any total breakdown. Indeed if
a Comma Server crashes, the Instrumentations it managed can ask for the help of
another Comma Server. The Adaptive Client Application will then reconnect
through the Comma Services API to the

new Source of the information. The
Recovery System within the Comma Services will put everything back in order in
a short time.


This extended connectivity of the new EEM also enables us to create more
complex and robust distributed systems and to provide

better monitoring to our
Adaptive Clients. We can connect Comma Servers between themselves, and
possibly develop new kinds of information Sources in the future, building new
dynamic patterns to fit our needs.



4.1.4.

Flexible


The first problem we encountered w
ith the former Execution Environment
Monitor that really provoked our need to improve the platform was its size. There
was no way to run a Comma Server on a Palm Pilot, even though we needed to
monitor the Palm Pilot’s resources.


The new EEM also solves
that problem: you do not need to run the whole Comma
Server, but just a much smaller Instrumentation server. Our new system lets the
computationally expensive work be carried out by the powerful machines, while
the resource
-
poor devices just have to manage

the computation of their local set
of Comma Variables.


34


4.2.

Projects based on the new Comma System


We present here some projects developed in the Shoshin Lab that made use of the
new Execution Environment Monitor.


4.2.1.

Comma Viewer and Manual Instrumentation


W
e developed the Comma Viewer and the Manual Instrumentation to provide a
demonstration of how the new EEM works at a meeting in Ottawa with Bell
Mobility, the sponsors of the project.


The Comma Viewer is an Adaptive Client Application. It uses the Comma
S
ervices API to register interest in some Comma Variable available somewhere in
the network. It also register as a Client for this Variable and waits for periodic
updates via callback. The Viewer runs a graphic user interface and displays the
changing value

of the Variable in the form of a graph.


The Manual Instrumentation is a local Java Instrumentation that also runs a
graphic user interface. It gives the user the possibility to create and delete Comma
Variables on the fly, and change their values with a
slider.



Comma Viewer
eem://linux/palm/mem
Variable:
Period:
5000
Submit
Comma Manual Instrumentation
mem
Variable:
Type:
125000
eem://palm/mem
eem://palm/cpu
eem://palm/screen
...
List of v ariables
eem://palm/mem
Long
Value:
500000
0


Figure 28.

The Comma Viewer and the Manual Instrumentation.




The two modules combined with the new EEM system enabled us to demonstrate
how an Adaptive Client Application can easily respond to stimuli from its
environment onc
e it has the proper monitoring tools.



35

4.2.2.

Palm Instrumentation


A second demonstration we gave in Ottawa for Bell Mobility was an
Instrumentation running on a Palm Pilot. That Instrumentation connected to a
Comma Server could provide general system informatio
n such as the memory and
CPU use of the small device. The Comma Server was running on a Linux IBM
laptop, and a Comma Viewer monitored the Palm Pilot’s system from a Windows
CE HP Jornada palmtop computer.





Figure 29.

Palm Instrumentat
ion demonstration.




This was a good example of how we can make Comma work over a group of
diverse operating systems and devices interacting with each other.



4.2.3.

Adaptive mapping software


A third Shoshin project is still under development at this time. It
consists of a
mapping software. A map server provides a map to a remote client. The client can
zoom in and out, and move North, South, East or West. The information on the
map is composed of elements. Each element is ordered according to the
importance: a
road is more important than a tree, but less important than a
highway.


We want to run the client on an HP Jornada palmtop computer. When the
resources of the Jornada are low, the information coming from the map server will
be filtered by the Service Proxy

module of the Comma platform. The Service
Proxies can indeed alter streams of data between two computers. It will monitor
the Jornada and decide to drop the less important information if the device is not
able to process it.



36

Map
Server
Map
Client
Client
Instrumentation
Comma
Service
Proxies
(f iltering)
Comma
Server
(monitoring)
mapping
data
filtered
mapping
data
client
resource
status


Figure 30.

Adaptive mapping software architecture.



This new software is a good example of what we hope to achieve in the Shoshin’s
Mobile Computing Project. The Client is adaptive and could well be wireless. The
server does the same job for adaptive clients (using

a Proxy) and non
-
adaptive
clients. The Comma system enables the wireless computers to join efficiently and
transparently the wired Internet.


37

4.3.

Future work


The new Executed Environment Monitor we presented is by no means the end of
its development. There
are still some small and also some bigger improvements
we need to work on. We present here some of the future work we think should
follow this one.


4.3.1.

SNMP Instrumentation


SNMP is a widely known and used network information source. We plan to
develop an Ins
trumentation that will offer the data SNMP provides through the
Execution Environment Monitor.


4.3.2.

Scheduler in the Comma Server


In the current Comma Server implementation, the Client Database runs one thread
for each Comma Variable registered by one of the
Server’s Clients. We could
very easily end up with hundreds of threads, and although they sleep most of the
time, they still carry an important overhead.


We are thinking about implementing an update scheduler for each Client of the
Client Database. This w
ould efficiently reduce the number of threads needed.


4.3.3.

Scenario Player Instrumentation


The Scenario Player Instrumentation could be an interesting tool to tune Adaptive
Client Applications. It would follow the Instrumentation interface, but would load
a “
scenario of values” for its Comma Variables from a file. This would enable the
replay of a string of events to see if the Adaptive Client Application behaves
correctly.


Once the Adaptive Client Application is properly tuned, it would use the real
monitori
ng Instrumentations to guide its behavior.


4.3.4.

Adaptive HTTP server and proxy


The Adaptive HTTP server or proxy could be an interesting Adaptive Client
Application to develop. It could monitor the state of the network and of the HTTP
client to adapt the cont
ent of its web page. For example it could change the
quality of pictures, remove the Java applets and convert objects from the web
page, to adapt to the HTTP client’s capabilities.


38

5.

Conclusion


The current developments of the Internet revolution are headin
g toward the wireless
world. However, the Internet was designed and built for wired networks and computers:
it does not work well when dealing with wireless devices. This inefficiency is due to the
fundamentally different Quality of Service behavior encoun
tered over wireless links.


Therefore Software for mobile and wireless systems must continually adapt to these QoS
dramatic changes and always make the best out of the current available resources. The
Shoshin Research Group developed a Communication Manag
er for Mobile Application
(Comma) to enable easier development of adaptive software. One of the Comma
platform’s components, the Execution Environment Monitor (EEM), is responsible for
monitoring the network and the resources of the system’s devices.


The
EEM, as it was designed in the first version of Comma, had serious limitations. The
architecture lacked flexibility, making the platform useless in creating adaptive
applications for small, wireless, resource
-
poor devices, such as palmtop computers and
PDA
s. We therefore decided to fully redesign the EEM architecture.


The main difference between the new version and the old one is the separation of two
functions previously carried out by the same server into two distinct entities: one
gathering information

about the environment (the Instrumentation) and the other sharing
this information with Adaptive Client Applications according to their needs (the Comma
Server). This scheme made the new architecture more flexible, dynamic and capable of
monitoring the en
vironment anywhere in the network, in particular in resource
-
limited
devices.


In the future, we plan to improve the performance of our system with a better thread
management. We will also extend it with new Instrumentations for both environment
monitoring

and adaptive application tuning. Finally we will develop new adaptive
software making use of the Comma platform such as web browsers, tourist guides and
MPEG players.


This internship gave me the opportunity to acquire significant practical knowledge abou
t
distributed systems. I had the chance to work on both system programming and the Java
platform. I especially enjoyed the discussion and sharing of point of views about the
project with the other members of the group.


39

Table of Figures


Figure 1.

The wireless device connection to the Internet.

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

6

Figure 2.

Architecture of the first version of the EEM.

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

8

Figure 3.

The former EEM’s Comma Client API architecture.

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

9

Figure 4.

The former EEM’s Comma Client API.

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

10

Figure 5.

The former EEM’s Comma Communication Protocol.

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

10

Figure 6.

The new EEM’s Architecture.

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

12

Figure

7.

The new Comma Server.

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

13

Figure 8.

The Instrumentation interface.

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

13

Figure 9.

The Source interface.

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

14

Figure 10.

The Comma Variable Data Structure.

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

15

Figure 11.

Example of Comma URL.

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

16

Figure 12.

Architecture of the new Comma Server.

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

17

Figure 13.

Architecture of the new Comma Server’s Client Database.

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

18

Figur
e 14.

The Distant Source Communication Protocol.

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

19

Figure 15.

The new Comma Range system.

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

20

Figure 16.

The Local Java Instrume
ntation.

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

22

Figure 17.

The Local Native Instrumentation.

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

22

Figure 18.

The Distant Instrumentation.
................................
................................
..........

23

Figure 19.

The Redirect System of the Distant Instrumentation.

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

23

Figure 20.

The Comma Services internal architecture.

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

24

Figure 21.

The Comma Services primary API.

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

25

Figure 22.

The Comma Services API for Registered Clients.

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

26

Figure 23.

The Comma Services Client Registration.

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

27

Figure 24.

The Source Database possible remote Source stubs.

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

28

Figure 25.

Example of connection to remote Source with redirection.

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

29

Figure 26.

The Comma Services API for Adaptability.

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

30

Figure 27.

The Comma Services Recovery System.

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

31

Figure 28.

The Comma Viewer and the Manual Instrumentation.

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

34

Figure 29.

Palm

Instrumentation demonstration.

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

35

Figure 30.

Adaptive mapping software architecture.

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

36