Group Title: lightweight collaborative API for ad-hoc mobile computing
Title: A lightweight collaborative API for ad-hoc mobile computing
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE ZOOMABLE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00100752/00001
 Material Information
Title: A lightweight collaborative API for ad-hoc mobile computing
Alternate Title: Lightweight collaborative API for mobile computing
Physical Description: Book
Language: English
Creator: Buszko, Dominik, 1974-
Publisher: State University System of Florida
Place of Publication: Florida
Florida
Publication Date: 2000
Copyright Date: 2000
 Subjects
Subject: Mobile computing   ( lcsh )
Application program interfaces (Computer software)   ( lcsh )
Computer and Information Science and Engineering thesis, M.S   ( lcsh )
Dissertations, Academic -- Computer and Information Science and Engineering -- UF   ( lcsh )
Genre: government publication (state, provincial, terriorial, dependent)   ( marcgt )
bibliography   ( marcgt )
theses   ( marcgt )
non-fiction   ( marcgt )
 Notes
Summary: ABSTRACT: In the recent years, mobile computing has emerged as a new discipline in the field of computer science. Due to advances in technology, portable computing devices have become more pervasive. From smart phones, and personal digital assistants (PDAs) running embedded operating systems, to portable computers running full-blown desktop operating systems, these devices have increasingly provided communication capabilities that utilize wireless connections. With those communication capabilities firmly established, the next logical step is in the direction of greater interaction between users equipped with such devices. However, current collaborative tools are ill suited for the demands of mobile networks, especially in situations in which no fixed-network infrastructure is present. In this thesis a framework and application programming interface (API) based on an architecture designed for mobile collaboration is presented. Additionally, an implementation of the framework, the API, and the sample client included in the API are described.
Summary: KEYWORDS: mobile, wireless, collaboration, Java
Thesis: Thesis (M.S.)--University of Florida, 2000.
Bibliography: Includes bibliographical references (p. 88-91).
System Details: System requirements: World Wide Web browser and PDF reader.
System Details: Mode of access: World Wide Web.
Statement of Responsibility: by Dominik Buszko.
General Note: Title from first page of PDF file.
General Note: Document formatted into pages; contains x, 92 p.; also contains graphics.
General Note: Vita.
 Record Information
Bibliographic ID: UF00100752
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
Resource Identifier: oclc - 47681463
alephbibnum - 002678648
notis - ANE5875

Downloads

This item has the following downloads:

edt5 ( PDF )


Full Text











A LIGHTWEIGHT COLLABORATIVE API FOR AD-HOC MOBILE COMPUTING


By

DOMINIK BUSZKO












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

UNIVERSITY OF FLORIDA


2000


































Copyright 2000

by

Dominik Buszko
















ACKNOWLEDGMENTS

I would like to express my sincere gratitude to my advisor, Dr. Abdelsalam

(Sumi) Helal, for providing me with an opportunity to work in this exciting area and for

providing feedback, guidance, support, and encouragement during the course of this

project and my graduate academic career.

I wish to thank Dr. Manuel Bermudez and Dr. Joseph Wilson for serving on my

supervisory committee.

I would also like to thank Harris Corporation for providing the Mobile Computing

Lab.

I would like to take this opportunity to thank my family and my girlfriend for

their emotional support and encouragement throughout my academic career. In addition,

many thanks go to my friends for making my stay at the University of Florida a very

memorable one

Finally, I would like to thank Maui Teriyaki and Krispy Kreme for providing

much needed nourishment for the long hours spent in the lab.
















TABLE OF CONTENTS

page

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

LIST OF FIGURES ............... .............................. .............. ......... vii

A B S T R A C T ................................ix.............................

1 INTRODUCTION ....................... .................. 1

W wireless C collaboration .................................................... .................... ............ 3
T h esis O bjectiv es .................................................................. .............................. . . 3
Structure of the Thesis ................................................... .. ...... .. ........ 4

2 REAL-TIME COLLABORATION AND GROUPWARE ................... ............... 6

Synchronou s C collaboration ............ .......................................................... .............. 6
Categories of Synchronous Collaboration......................... ....................... 8
Focused Collaborative Applications ........................... ....... ....................... 8
Unfocused Collaborative Applications ...................................... .............. 9
D design Criteria ........................ .. .... ....................... .......... 10
Elements of Synchronous Collaboration....................... .............................. 11
Collaboration Context Com ponents ................................................... .............. 11
C h at ........... ........................................ .......... ............... 11
Shared W hiteboard ............. .. ..................................................... ..... ...... .. 13
Telepresence ............... ......... ................. 14
Virtual Spaces ......................................... 16
Shared Applications ............ ...................................... ...... ............ .. 17
Awareness of Other Participants.................................................................. 18
Collaboration Management and Coordination.................... .. ................... 19
Session M anagem ent .......... .... .. ... ...................... .. ......... . .. ............ .. 20
Floor Control ......... .... ..... ............. ........ 21
Event M anagem ent .............................. ......... ............ ........ ....... 22
C current A PIs and Products .............. .............. ............. ......................... .............. 23
N CSA H abanero........ ........ .............. ......... ............... ............ .. 23
O overview .................. .................................................................................. 23
A rchitectu re ............................................................................................... 24
E v alu action ................................................................................... .............. 2 6
N etM eetin g SK D ........................................................................................ ........ 2 7



iv









O v e rv iew ..................................................................................................... 2 7
A rchitectu re ..................................................... 2 7
E v alu action ................... ................................. 2 9
Jav a Shared D ata T oolkit .......................................................................... ........ 29
O v e rv iew ..................................................................................................... 2 9
E v alu action ............................................ 30
A PI' s Com prisons .............. ................. ........... ......... .... 30

3 ARCHITECTURE FOR AD-HOC WIRELESS COLLABORATION ..................... 31

Characteristics of the M obile Environm ent ............ ................ .............. .............. .31
B andw idth and Latency........................................................... ......................... 32
Processor Power ......................................................................... ......... ................... 32
Display Size............................................... ........ 34
B battery L ife .................................................................................................. 34
Input M methods ........... ... ...... ................................................................. 35
K e y b o a rd ................................................................................................. 3 6
Pen .............. ........ ................................ 36
V o ic e ......... ............ ........... ..................................................................................... 3 7
De-centralized Control .................. ......... ......... ........ 38
P ro x y le s s ................................................... .............................................. 3 9
F ault T olerance.............................. .................... 39
A d-hoc M ability ................................................................................. ............. 40
M message B asked .................................................................................... ................... 40
T ra n sp o rt L ay er ................................ .................................................................. 4 0
User Datagram Protocol ........ ......... ................. ........ 41
M u ltic a st .................. ....... .................... ................................... 4 1
Event Replication and Synchronization ...... ......................................... 42
Support for Decentralized Control ................ ................ ........ ........... 43
B andw idth R equirem ents ............................................... 43
Ordering of Messages ............... ......... ........ ........ 43
A d -h o c N etw o rk in g ...................................................................................................... 4 3
IEEE 802.11 Ad-hoc N etworking ......................................................... ...... 44
Private Networking ............................................ .......... ....... 45
R outing ................................................................................................... 4 5
N am ing Conflict Resolution .............................................................. .............. 46
R ecov ery ..................................................... 4 6
Leader Election ......................................................... ................... 47
S session State ..................................................... 4 7

4 Y C A B SE R V IC E S ........................................................................................ 49

S erv ic e s ..................................................... 4 9
Leader Election Service .. ........... ............ ....... .............. 50
D description and U sage ........................................ 50
Implementation................... .. ........ 50
Session M manager Service ........................................ 51









D description an d U sag e .......................................................................................... 5 1
Im plem entation ...................................... .............. .................. .. ................ 52
Session Ping Service ........................................... ................ 53
D description an d U sag e .......................................................................................... 53
Im plem entation ...................................... .............. .................. .. ................ 53
T ext C hat Service .................................................... 55
D description an d U sag e .......................................................................................... 5 5
Implementation................... .. ........ 57
W hiteboard Service ....................................................... .. ..... ................ 57
D description an d U sag e .......................................................................................... 5 8
Implementation.................. .. ............................... 62
Im age V iew er Service ..................................................... .. ....... .. .... ... .... .. 64
D description and U sage .......................................................................... .... ... 64
Implementation.................. .. ............................... 66
G P S Service............................. .............. ...... 67
D description and U sage ................................... ............ ............... ......................67
Implementation................... .. ......... 69
C lient Info Service ........................................ ........ ............ ............ 70
D description and U sage ......... ............... ........................................ .............. 70
Implementation................... .. ......... 72
Service Summary .......... ............. .... ......................... 73
A PI O ptim izations ....................................................... .......... .. ............73

5 DEVELOPING A CUSTOM SERVICE USING YCAB API................................... 75

6 CONCLUSION S AND FUTURE W ORK .................................................................... 86

L IST O F R E F E R E N C E S .................................................................................................. 88

BIOGRAPHICAL SKETCH ....... .................................................. .............. 92
















LIST OF FIGURES



Figure Page

1 Layers of a collaborative system .............. ............. .......................... .............. 20

2 Two users drawing simultaneously. The desired behavior (left). The behavior
with implicit floor control (right). ....................................................... 22

3 Structu re of H ab an ero ................................................................................................ 24

4 H ab an ero arch itectu re. ................................................................................................ 2 5

5 NetMeeting SDK architecture (source: Microsoft NetMeeting SDK)..................... 28

6 Palm PilotTM.................. .................................... ............... 37

7 Ad-hoc routing. (left) Ad-hoc routing is not available; therefore client A cannot
communicate with client C. (right) With ad-hoc routing, client A can
communicate with client C through client B..................................................... 46

8 U ser interface of Text Chat service. ........................................ ...................... 55

9 User interface for the W hiteboard service. ............. ................................ ....... ....... 58

10 User interface for the Image Viewer service. .................................. .............. 64

11 User interface for the GPS service .............. ... .................................... 67

12 User interface for the Client Info service.............. ............................ .............. 70

13 Basic skeleton code for a service. ........................................... ........................ 76

14 The init () method for the text chat service. ............................... ............. 78

15 Constructor code for the text chat service............................................ ... ... .............. 78

16 Optimized YCab application with a single service.......................... ........... ... 79

17 Code for the processMessage () method. ................................. .............. 80









18 Sample usage of the send () method ......................................................... ........ 81

19 Complete code for the actionPerformed () method for the text chat service. 82

20 Complete code for the text chat service. ...................................................... 84















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

A LIGHTWEIGHT COLLABORATIVE API FOR MOBILE COMPUTING

By

Dominik Buszko

December 2000


Chairman: Abdelsalam (Sumi) Helal
Major Department: Computer and Information Science and Engineering

In recent years, mobile computing has emerged as a new discipline in the field of

computer science. Due to advances in technology, portable computing devices have

become more pervasive. From smart phones, and personal digital assistants (PDAs)

running embedded operating systems, to portable computers running full-blown desktop

operating systems, these devices have increasingly provided communication capabilities

that utilize wireless connections. With those communication capabilities firmly

established, the next logical step is in the direction of greater interaction between users

equipped with such devices. However, current collaborative tools are ill suited for the

demands of mobile networks, especially in situations in which no fixed-network

infrastructure is present.

In this thesis a framework and application programming interface (API) based on

an architecture designed for mobile collaboration is presented. Additionally, an









implementation of the framework, the API, and the sample client included in the API are

described.














CHAPTER 1
INTRODUCTION



Handheld devices make an ideal platform for applications requiring data sharing

and mobility. Field sales and support, financial services, insurance, healthcare, and

transport business segments all benefit from mobile enterprise applications such as order

entry systems, asset management systems, on-site inventory control, and package

tracking systems by taking advantage of the mobility that handheld devices provide.

Many of these systems are used in the enterprise environment to allow multiple users

access to shared data, enabling geographically disperse teams to collaborate on a project.

The same systems also allow mobile employees who travel from meeting to meeting to

access the same wealth of information that co-workers share at their desktops. Travel

time that used to be unproductive can now be harnessed to increase productivity and

decrease the response time of employees. With the recent explosion of the Internet and

its role in enterprise business, customers demand quick response time, requiring

corporations to adapt and evolve at a much faster pace than ever before.

While many aspects of business have kept up with the changing technology, many

of the slower aspects of business, such as travel, have not. The time it takes to share data

across the corporate Intranet has become almost zero, while travel-time from location to

location has practically remained the same. Travel-time typically means downtime

because critical shared data such as schedules, addresses, messages, and e-mail are

typically unavailable. Wireless handheld technology is rapidly changing that notion by









providing the necessary tools, such as access to Intranet data, to keep mobile users

connected and productive. Although many of the applications described have proven to

be mission-critical, they only provide collaboration between users that is asynchronous.

Since the information shared between users is delivered asynchronously, the process of

creating ideas remains an individual task. The next step in collaborative software enables

users to interact and share data synchronously [21].

Synchronous collaboration between participants ensures that data is shared in

real-time, resulting in real-time collaboration. The typical team communicates in a way

that is analogous to a classroom environment. However, the one notable exception is the

amount of interaction between team members. The project manager, i.e. the teacher,

usually leads the meeting with an agenda and asks for input from the developers or

engineers, i.e. the students, typically leading to spontaneous creation of information and

ideas that are shared immediately. This type of interaction has an advantage over

asynchronous collaboration in allowing for the actual creation process to be shared rather

than just presenting an idea after brainstorming individually. While synchronous

collaboration does have its advantages, it in no way nullifies the facilities provided by

asynchronous collaboration, but rather complements them.

Although synchronous delivery of information is useful for providing a venue for

solving specific problems, such as a particular engineering challenge, it does not supply

the tools needed for workflow management. Existing products such as Lotus Notes [20]

incorporate e-mail, calendaring, group scheduling, contact, and task management. These

workflow management tools are the main domain of asynchronous collaboration. Real-









time collaboration brings a set of facilities that not only complement but also enhance

such tools by giving the users more options in sharing ideas.




Wireless Collaboration

The same challenges that apply in a "real" meeting also affect "online"

collaboration. Since everyone participating in a real-time session must be present in the

virtual space concurrently, scheduling a time that is suitable to all participants is a

problem. The need to access a suitable workstation that is capable of supporting such a

session compounds the problem. Wireless collaboration may help solve the problem of

finding a suitable time between all participants because location dependencies are

eliminated. For example, time spent in transit from location to location can now be

utilized. The convenience and location flexibility also allows participants to participate

in a more comfortable location, perhaps contributing to a more creative and productive

environment.




Thesis Objectives

The main objective of the work described in this thesis was to design a framework

for wireless ad-hoc collaboration and to provide an API that would enable developers to

create custom services and applications using the framework. The goals are summarized

as follows:

1. Propose a framework for use by collaborative services in a wireless ad-hoc

network.









2. Provide a lightweight API that allows developers to create small, and highly

optimized collaborative applications that can run on mobile devices.

3. Provide a flexible API for developers so as to facilitate rapid application

development.

4. Implement the framework in Java for deployment over a number of

heterogeneous devices.

5. Develop services that will include text chat, shared whiteboard, shared images,

and global positioning system navigation.

6. Develop a sample application using these services.




Structure of the Thesis

In Chapter 1, introductory remarks about the scope of the thesis are provided. The

reasons for developing an API for wireless collaboration are also examined.

A literature survey and collaborative concepts are presented in Chapter 2. This

chapter concentrates mainly on the collaborative concepts, as they exist in the existing

fixed-network environment.

In Chapter 3, the characteristics and architecture of a mobile environment are

described. The issues that need to be considered in the design of the mobile collaborative

system are examined. Finally, the architecture for such a system is proposed and its main

characteristics evaluated.

The services that are included in the API are described in Chapter 4. This chapter

includes a detailed description of each service and its purpose. Additionally, general

usage and implementation details of each service are provided.






5


In Chapter 5, a tutorial for designing a custom service is provided. This tutorial is

geared towards developers who wish to fully take advantage of the API, and who wish to

extend its functionality.

Finally, the evaluation of the system and the API is provided in Chapter 6. In

addition, ideas for improving the design of the system are also proposed.














CHAPTER 2
REAL-TIME COLLABORATION AND GROUPWARE




Synchronous Collaboration

With ubiquitous connectivity on the horizon, collaborative computing promises to

become one of the core applications in the near future. But, what exactly is collaborative

computing? First, a distinction has to be made between synchronous and asynchronous

collaboration [37]. Synchronous collaboration, or real-time collaboration, occurs when

the collaborators' interactions are simultaneous or near simultaneous (separated by very

short periods of time, seconds or minutes at the most). On the other hand, asynchronous

collaboration occurs when the collaborators' actions are separated by relatively long

periods of time (hours or even days). In most cases, asynchronous collaboration simply

indicates that several users have access to shared data [1]. This chapter deals primarily

with synchronous collaboration and issues that exist in such systems.

There is no single definition that can be used to describe synchronous

collaboration. Synchronous collaboration can be used in many ways and has a broad

range of applications, examples of which are given below.

Interactive meetings a group of collaborators work simultaneously to achieve a

common goal, with all participants more or less equally contributing to the

session. In general, interactive meetings tend to involve small groups of

participants and do not require a large amount of policing.









Remote teaching or conferencing involves a group of collaborators with one of

the collaborators acting as a presenter, and the rest of the participants assuming

the role of an audience. In this setting the presenter is in charge of the session and

is the most active collaborator, while the rest of the participants assume more

passive listener roles. Such situations usually involve some kind of distributed

slide presentation.

Concurrent application usage the collaborators simultaneously use the same

application, instead of independently working on the same project.

Multi-user application development toolkits a group of collaborators

simultaneously use a particular development tool to develop new applications.

Virtual environments collaborators meet in a fixed and pre-defined environment

either for business or informal collaboration.

Group workflow collaborators use the system to coordinate group activities.

Shared simulations and experiments collaborators concurrently perform and

monitor the progress of an experiment.

As can be seen from the above examples, synchronous collaboration covers a

wide variety of applications [24, 31, 41, 44]. However, all these systems share certain

root features that are common to all collaborative environments. The differences stem

from the various ways of implementing and integrating collaborative components. In

essence, synchronous collaborative applications can be customized to suit specified

requirements.









Categories of Synchronous Collaboration

Real-time collaborative applications can be further divided into two categories:

focused and unfocused. These categories are based on the type of content that is to be

shared by these applications. Both focused and unfocused applications co-exist, because

each of them is more suitable for certain type of collaborative tasks. The advantages and

disadvantages of each type dictate whether an application of a certain type will be

applicable to a given situation.



Focused Collaborative Applications

In focused collaborative applications, the content of what is shared is factored into

the application. The information that is shared is typically geared and optimized towards

a specific task or situation. An example of this is instant messaging.

One of the advantages of focused collaborative applications is that they have

relatively small resource requirements. Since the application is aware of the content

being shared, it can be designed and implemented to expect certain input and behavior,

and at the same time, eliminate many unfeasible values. The specificity of the data

allows the protocols to be highly optimized as well. This applies to both the information

shared as well as the exceptions encountered. Error checking can also be reduced.

Another advantage is that the interface can be more user-friendly than the user interface

of unfocused applications, since the data can be presented in a consistent manner. If the

information to be shared is specific, then the graphical user interface (GUI) of the

application can be optimized around that data.

The main disadvantage of focused collaborative applications is their poor

adaptability in situational usage. Applications designed with a focus in mind tend to be









designed with a specific situation in mind. At the time of creation, the requirements are

defined, but in the course of the software lifetime, the requirements may change either

due to an update of the business model or fluctuations of the market. Another

disadvantage is restricted scalability in features. The optimization of the code could

prevent future additions of user-requested features. Although some such features can be

foreseen, most of them cannot.



Unfocused Collaborative Applications

Unfocused collaborative applications do not distinguish the type of information

shared. The content is shared generically, making them more flexible than focused

collaborative applications. Examples of this include Microsoft's NetMeeting [29] and

NSCA Habanero [27].

The main advantage of unfocused collaborative applications is their great

adaptability in situational usage. Since the information that is shared is of no concern to

the application, anything can be shared. This allows for more situations in which the

software can be used. For example, the same application can be used by structural

engineers to share a blueprint for a building or by an author to share text with a publisher.

Another advantage of unfocused collaborative applications is their feature scalability.

The same reasoning applies for this case as it does with the adaptability issue. Since the

data that is shared is generic, applications can be shared as well. The feature scalability

of unfocused collaborative applications is limited only by the applications that are shared.

One of the disadvantages of unfocused collaborative applications is their high

resource requirements. Because the data shared is not specific, contingencies for

different types of data must be factored in. The generic nature of the data prevents the









protocols from being optimized. This applies to both the information shared and the

exceptions encountered. Thus, error checking must be increased. Another disadvantage

of unfocused collaborative applications is that their user interface tends to be less user-

friendly since the data cannot be presented in a consistent manner. If the information to

be shared is not specific, the GUI becomes very difficult to optimize around the data.



Design Criteria

When asked to create a collaborative piece of software, the proper type of

application to implement can be determined according to the limitations provided by the

given environment. Unfocused collaborative applications such as NetMeeting are best

suited for devices with powerful processors, unlimited battery power, access to high

bandwidth, and large display sizes. These applications generally provide a suite of tools

for data sharing and communication. Some of these tools include audio and video

conferencing, shared whiteboards, text chat abilities, file transfer among clients, program

sharing, and desktop sharing. While many of these tools such as program and desktop

sharing, are very useful, they consume massive amounts of resources that are not

available in handheld devices that are currently on the market. With the ability to

optimize the protocols and GUI's, focused collaborative applications are particularly well

suited to resource-limited devices. Since low processor power, limited power, bandwidth

limitations, and limited display size are prominent in today's handheld devices, most

collaborative applications developed for mobile devices should be implemented with a

focused mindset.









Elements of Synchronous Collaboration

In this section, the major components and concepts that are used to implement

collaborative systems are described.



Collaboration Context Components

In this section the components that can be used to implement collaborative

systems are discussed. Each of these components can be implemented as a standalone

application to accomplish a minimal level of collaboration, but combining them with

other collaborative components delivers a more robust collaborative system.



Chat

Perhaps the most common feature of a collaborative environment is chat. After

all, the main goal of collaboration is the exchange of information, and verbal

communication is the most common of way of communication. There are two main

types of chat: text chat, and audio chat In the past, due to limited network and

computing resources, text chat was the only viable option. The user would simply type

on his console the message he wanted to communicate. The key advantage of this

approach was that it did not require extensive resources such as network bandwidth or

high computing power, and therefore was fairly ubiquitous, since any terminal or console

with text capabilities could be used. Another advantage was that it is, or can be, very

anonymous, which in some cases helps to break down social and cultural barriers. On the

other hand, message-based collaboration tends to inhibit the flow of collaboration, and

requires the participants to be very clear and precise in their messages since, their text


1 Also referred to as voice chat.









message is the only way of conveying the intended information. It does not work very

well for larger groups of collaborators, where it is difficult to keep up with a large

amount of text scrolling on the screen. Having multiple discussion threads complicates

matters even further, as users have trouble following the threads, especially when the

discussion is not moderated. Another issue to consider is the users themselves. In most

cases, especially with users without computer background, the users' typing speed is just

too slow in order for the chat to be effective.

The audio chat in a collaborative setting can be implemented in two ways. One is

to simply use the existing voice phone capabilities and use them alongside the

collaborative solution. In this setting an existing phone line would serve as a channel of

communication, while the network channel would provide data exchange services. The

problem with this scenario is that it is not applicable for large group of collaborators who

are in different locations, since phone lines can only provide one-on-one, or at most

three-way, communication. The other, more advanced, way is to utilize some of the

newer compression schemes or voice-over-IP technology to deliver voice using packet-

based networks. As technology has advanced, audio chat (voice interaction) has become

more feasible. In either case, the user simply speaks to a microphone, or other recording

device, and converses with other participants using verbal means of communication.

This greatly improves the efficiency of collaboration, because for one, to most users

verbal communication is much more natural and they can much quicker convey an idea

by talking about it rather that trying to describe it in writing. In addition, full-duplex

voice chat most closely simulates actual conversation, and allows participants to

communicate a great deal of subtle information through inflections and nonverbal cues

[31].











Shared Whiteboard

Another common feature in a collaborative environment is a shared whiteboard.

A shared whiteboard provides participants with a common area that can be used to

visually exchange ideas with the aid of a "whiteboard" that is visible to all users. In its

most rudimentary form, it provides the user with some basic drawing and erasing tools,

which can be used to quickly sketch simple pictures or graphs. Shared whiteboards

usually have the ability to accept either pen-based or mouse-based input, depending on

the device used. Regardless of the input method, the basic behavior of a whiteboard

remains the same, and can greatly enhance collaborative sessions. This is especially true

in situations in which providing a written description of some concept or an object would

be overly time consuming and could be more easily achieved with a simple sketch or

graph [17]. There are numerous such situations: providing someone with directions to a

particular location, describing a given hierarchy, or presenting a chart or a graph. More

advanced versions of shared whiteboards have provisions for importing and sharing all

kinds of image types, and even presentation slides. Other features that can be added to

enhance a functionality of a shared whiteboard would be character and symbol

recognition, and the inclusion of pre-defined shapes or symbols [26]. Character

recognition would allow the user to simply use handwriting to communicate short

messages. The message would then be replicated as plain text, instead of replicating a

graphical representation of it. Predefined shapes or symbols would aid in situations in

which agreed upon symbols are used to represent abstract entities. For example, a group

of network engineers could use a shared whiteboard with pre-defined symbols for

servers, routers, switches, terminals, etc., to collaborate on the design of a network [6].









In a fashion similar to the situation with text recognition, using pre-defined symbols

would enable the system to replicate symbol codes to each client, instead of sending the

actual symbol to all collaborators.



Telepresence

The ultimate goal of collaboration is to present each participant with an

environment such that there would be no difference between the online collaboration and

the actual in-person conversation, in which the in-person collaboration would have no

advantage over remote collaboration. Telepresence helps to achieve that goal by means

of several different techniques.



Telepointers

Telepointers are used to increase the awareness of other session participants'

actions. Telepointers are especially useful in certain types of applications such as text

editors, because they enable the participants to see which part of the document the other

collaborators are working on. Telepointers are also used to give each participant his own

pointer that is independent of the other participants' pointer. This way each collaborator

controls his own pointer and the group can truly collaborate synchronously, as opposed to

situations in which the whole group works together, but shares a single, common pointer.



Video

Only recently has video become feasible for use in collaborative environment.

The presence of video provides the following key advantages:









It helps establish trust between participants by conveying their attitudes via facial

expressions and their commitment by showing continued attention. As in a face-

to-face meeting, participants can see each other and gauge their level of interest.

The participants can also visually determine whether they are successfully and

clearly conveying an idea.

It establishes a continuous sense of the direction of the session by allowing

participants to interact in real time.

It facilitates the explicitness necessary for carrying out a set of instructions, which

frequently requires some form of face-to-face interaction.

The main disadvantage of video is that the additional features and functionality,

which greatly enhance a collaborative system, also significantly increase the

requirements for such a system. Even low-resolution video requires significant

bandwidth and the required bandwidth quickly adds up considering that the video needs

to be sent to every session participant. At the same time, the clients' capabilities also

need to be taken into consideration to ensure that the system used for viewing is actually

capable of properly displaying the received video [2].



Avatars

One way of enhancing the telepresence is by use of "avatars". Essentially, an

avatar is a graphical entity associated with a particular session participant. This allows

each participant to establish his own identity. Avatars are usually used within some fixed

session boundaries, such as a "virtual space." 2 Avatars are much better suited for a

casual setting such as a party or informal gathering, and they tend to be humorous in


2 Also known as "virtual rooms"









nature. To allow for communication between avatars, they are usually tightly coupled

with either a text- or voice-based chat. Avatars not only help participants establish their

identity, but allow participants to more closely reproduce the real-world environment. As

in a real-world setting, avatars have the ability to move around their environment and

move closer to or away from other participants. This greatly enhances the awareness of

other participants, which is not possible in a purely text, or even voice-driven, chat

session.



Virtual Spaces

Virtual spaces attempt to establish a common environment for all session

participants. The goal of a virtual space is to closely reproduce an everyday environment.

Most people have an easier time understanding and using new technology, if they can

relate it to something familiar. For example, a virtual space that models an office

building with meeting rooms, private offices, lecture halls, front lobby, etc., is more

easily identifiable to an office worker than just a regular online collaboration session.

Virtual space gives participants the ability to "virtually" go to a meeting, leave such a

meeting, have an informal chat with a friend in the lobby, etc. [28]. To successfully

implement a virtual space3 one can utilize any of the components described above, such

as text or audio chat, video, whiteboard, etc. Virtual spaces tend to be more permanent

than collaborative sessions. When a group of collaborators ends their session, the session

itself usually disappears, and the only thing left is the transcript of the session. However,

in a real-world setting an office building and all the information contained within does

not disappear just because no one happens to be in that building at a particular time.


3 Also known as Virtual Workspace









Virtual space techniques try to closely replicate that environment, in which the

environment itself is fixed and always present. This in itself increases the efficiency of

collaboration, because it eliminates the time needed to set up the session every time users

wish to collaborate. Furthermore, various artifacts can populate such environments.

Examples of such artifacts would be session transcripts, shared whiteboards from past

sessions, or other items that could potentially be re-used. As in an actual office, these

artifacts can be brought in by other participants, moved between different rooms or

sessions, or simply viewed by anyone with access to them. Such a persistent virtual

space would essentially serve not only as a collaboration mechanism, but also as storage

space.



Shared Applications

Another aspect of synchronous collaboration is application sharing. Instead of

creating dedicated applications for collaborative environments, regular single-user

applications are shared among the collaborators with the aid of a centralized server.

Unlike inherently collaboration-aware applications, application sharing is classified as a

collaboration-transparent process, because the system shares existing single-user

application-utilizing mechanisms that are transparent to the application and its

developers. Essentially, the server runs a single copy of the application, and then

propagates only display information and related environment data, such as mouse events,

to other clients. This most closely simulates a thin-client environment in which the client

is essentially a "dumb" terminal that displays information and is capable of registering

input from the user and sending that input to the server, which in turn performs all of the

necessary processing. Since this approach does not require any modification to the









existing application, it appears to be a great solution. However, a thorough evaluation of

this approach reveals that the set of requirements for collaborative environment is vastly

different from a single-user environment and that presents a number of challenging

problems. Such a conventional collaboration transparency system is inefficient in its use

of network resources and lacks support for key groupware principles such as concurrent

work, relaxed "what you see is what I see" (WYSIWIS), and group awareness [3]. Some

have proposed a hybrid approach in which the existing applications are not just

encapsulated in the collaborative environment, but instead adjust to such a environment

during run-time. Such adjustments are transparent to the user and include features such

as replacing single-user application components with ones that are designed for multi-

user collaboration, during runtime.



Awareness of Other Participants

The awareness of other participants (or the session awareness) deals with all the

issues that are related to being able to know who is "around", what activities are

occurring, who is talking with whom, etc. [10, 22]. In real-world situations, people use

all of their senses to monitor and interact with their surroundings. However, this is not

possible in a distributed session, due to the collaborators being geographically dispersed.

The lack of physical presence results in several problems. For example, one of the

problems with remote teaching and conferencing is that the presenter has virtually no

way to gauge the interest level of the audience, and that makes it difficult to make

adjustments.

Various means have been devised to increase the overall awareness of the

collaborative session. Since awareness is strongly tied to telepresence, components such









as high quality positional audio and video have a direct impact on the overall awareness.

In the future there are plans to provide awareness for other senses, mainly the senses of

touch and smell. The addition of these features would make sessions even more realistic,

being able to actually feel a given part, or even being able to smell the coffee that

someone brought into the room in some other location [10]. Another way of contributing

toward the increase in awareness would be to utilize a Global Positioning Satellite (GPS)

receiver. This setup would be especially helpful in ad-hoc groups, and would enable

users to determine their actual location on the map, as well as their location relative to

other participants.



Collaboration Management and Coordination

A large part of any collaborative system is the environment that provides the

underlying infrastructure required for successful collaboration. In most cases

collaborative systems are based on the typical client/server paradigm. Such systems

usually consist of a centralized server that is used to host the session. The server runs

specialized software for managing and supporting the session. The session collaborators

are the clients that communicate with the server. The clients run client software that is

vastly different from the server software. In order to facilitate expansion of such

collaborative systems, the systems often include the API to the environment. This is the

layer that lies between the collaborative application and the hardware itself (see Figure

1). The API, short for Application Program Interface, is a set of routines, protocols, and

tools for building software applications [40]. An API makes it easier to develop a

program by providing many building blocks. A programmer puts the blocks together.

Most operating environments, such as MS-Windows, provide an API so that









programmers can write applications consistent with the operating environment. Although

APIs are designed for programmers, they are ultimately good for users because they

guarantee that all programs using a common API will have similar interfaces. This

makes it easier for users to learn new programs.








i







Figure 1 Layers of a collaborative system.



Several steps must be taken in order to ensure that the collaborative session flows

smoothly. Especially important are session management, floor control, and event

management.



Session Management

The session manager is responsible for managing a session. The concept of

session can be defined as a group of entities associated with some common

communication pattern [4]. The session manager keeps track of the session participants

and the overall status of the session. It must allow a client to join late in the session and

ensure that the new client is quickly brought up to date by the event manager, so that the

state of the session remains consistent. The session manager must also gracefully handle









client disconnection, so that one person's premature or unexpected departure does not

disrupt the flow of collaboration. This is especially important in cases in which the

disconnection was unforeseen, and the disconnected client had acquired access to some

shared resource before being disconnected.

In systems in which security requirements are very strict, the session manager

must also ensure that an unauthorized client does not compromise the system's security

and integrity. Additionally, the session manager can provide archiving facilities that

would enable collaborators to archive and later retrieve the proceedings of past sessions.



Floor Control

Floor control is widely used as a synchronization mechanism. The idea behind it

is that even though several people participate in a collaborative session, only one person

at a time may actually "hold the floor" [3]. The challenge is in designing such a system

where the floor control mechanism automatically adjusts to the situation at hand and does

not add unnecessary complexity or overhead. For example, in a classroom environment

the teacher is in control of the floor, and he is the only person making decisions regarding

who should hold the floor next. Such a system deals with an explicit floor management,

where each participant must explicitly request the floor, or for that matter, any shared

resource. This is different from a meeting environment in which every member

contributes equally to the session, and for the most part the session is self-moderated. In

such cases explicit floor control would be a nuisance and would inhibit the flow of work.

Implicit floor control is more appropriate for such a case, and the floor control is

equivalent to a first-come-first-served basis, in which any users' action would implicitly

request the floor. However, even with such implicit floor control problems can arise. For









example, consider a situation in which two users try to simultaneously draw parallel lines

(Figure 2, left) in the common area. If implicit floor control is used then the control will

jump from one user to another and the mouse events from both users will be interleaved.

This will lead to incorrect behavior as shown on the right in Figure 2.












USEla R USER I SJV ] R

Figure 2 Two users drawing simultaneously. The desired behavior (left). The behavior
with implicit floor control (right).





Event Management

Event management deals with problems related to replicating events to all session

participants. In a centralized architecture there exists one server (or perhaps a centralized

group of servers working together), which acts as the "hub" for communication between

the clients. In an event-driven model of collaboration where each user's actions are

represented as a series of events generated by the user, the event manager ensures that

each event that is supposed to propagate to all clients does indeed propagate. The event

manager must also ensure that all the clients receive the events in exactly the same order

so that the state of the session remains consistent. Additionally, the event manager must

keep a history of events that occurred, or at least enough past events that would enable









any newly joining client to be quickly brought to a state that is consistent with the state of

the session.




Current APIs and Products

In this section some of the currently available APIs that deal with real-time

collaboration are described and evaluated. Specifically, it describes three currently

available products: NCSA Habanero [27], Microsoft NetMeeting 3 SDK [29], and Sun

Java Data Shared Toolkit (JDST) [14].



NCSA Habanero

Habanero is a Java-based collaborative framework and set of applications

developed at the National Center for Supercomputing Applications (NCSA) at the

University of Illinois at Urbana-Champaign [27].



Overview

The Habanero framework enables developers of groupware applications to build

powerful software for real-time collaboration in a reduced amount of time. The

Habanero framework provides all the necessary methods that the developers can use to

create or convert existing applications into collaborative applications called Hablets.

Habanero is written in Java and runs under any operating system that supports Java 1.1.

Habanero is divided into two parts: environment, and the framework (see Figure 3).










H aba nero






:1 .- t



Figure 3 Structure of Habanero.



The Habanero environment consists of a client, a server, and the applications. Its

main purpose is to display shared information. The Habanero framework consists of the

API. The API includes all the networking facilities as well as the serialization,

arbitration, and routing software necessary to share state data and key events between

multiple applications. The goal of the API is to facilitate sharing of information. There

is no inherent limit on the number of tools per session, nor is there a limit on the type of

tools that can be shared.



Architecture

The Habanero environment consists of a server and a client (or usually several

clients) in the standard Internet paradigm (see Figure 4). The environment is built using

the Habanero API. To accomplish the goal of sharing Java objects, the Habanero server

provides software mechanisms for arbitration, routing, and networking. Habanero is

based on the notion of replication, where data and events in each client are under the

control of an arbitrator at a single server. However, due to its design, Habanero works

equally well in the client-server paradigm or replicated paradigm as well as all stages

between them.













Session I


Season 2


Figure 4 Habanero architecture.


Habanero Server

The purpose of the Habanero server is to act as session host for the clients. It is

also responsible for replicating information to all clients, and at the same time acts as the

arbitrator. All Habanero applications communicate with the clients, which in turn send

information to the server. Once the server receives the information, the server sends that

information to all clients in the given session. The server consists of a few major

components that work together in order to support a collaborative system.

Serializer this component takes advantage of Java's ability to serialize4 objects.

Serializer also assigns a ticket to each object to ensure that all objects or events

occur in the same sequence on every client.

Arbitrator this component is used to establish a central point of control. This

floor control mechanism ensures smooth workflow. The arbitrator determines the

order of events based on the tickets (assigned by the serializers) associated with

each event or object. This has the additional benefit of implementing a minimal



4 The ability to easily send all types of objects or events over the network









level of authentication, since clients are instructed not to execute events that do

not have a ticket assigned to them. In addition, the arbitrator can be used as a

synchronization mechanism.

*Communication Manager this component performs the role of a router for the

collaborative session. Communication manager ensures that all the events that are

supposed to be propagated to all the clients are in fact propagated.



Habanero Client

Habanero clients communicate only with the server. The Habanero server then

communicates with the other clients. Although the clients are aware of all other clients in

the session, no direct communication between clients is allowed. A client has the ability

to either create a new session or join an existing session, provided that the server and

session information are available. In addition, clients have the ability to identify other

session participants, display tool information, display participant information, define the

tools available for that session, etc.


Evaluation

Habanero is a research project. Its goal is to provide a generic, cross-platform

framework that can be used to cover the gamut of collaborative applications for a variety

of users. The goal set by the Habanero developers, was to make the Habanero API as

nonspecific as possible. This would allow the API to be applicable to a broad range of

applications ranging from collaboration between a few individuals located in the same

room to a significantly large group spread throughout the globe attending and

participating in a virtual conference. The result of this is that the framework and the API









are not optimized for any particular type of collaborative applications, which may hinder

its performance under certain circumstances.



NetMeeting SKD

This section provides an overview of the Microsoft's NetMeeting Software

Development Kit (SDK) [14].



Overview

NetMeeting delivers an open, extensible platform for real-time communications,

offering audio, video, and data conferencing functionality. The NetMeeting 3 SDK

provides software API support for applications that are NetMeeting clients [43].



Architecture

The NetMeeting architecture can be broken down into several integrated

components (see Figure 5), each designed to perform a specific task. Among the

standards supported by NetMeeting are the ITU H.323 standard for audio and video

conferencing, the ITU T. 120 standard for multipoint data conferencing, and the IETF

LDAP standard for directory services [29].



















Figure 5 -NetMeeting SDK architecture (source: Microsoft NetMeeting SDK).


* Conferencing API The NetMeeting conferencing API takes advantage of all the
functionality provided at lower layers including the optional NetMeeting user
interface (NetMeeting UI).
Control Layers (NetMeeting UI, and Node Management) these components tie
together the NetMeeting functionality provided by lower layers. The Control Layer
is responsible for keeping track of conferences and session participants, and
displaying NetMeeting functionality to users.
Audio/Video Components (Call Control, RTP/RTCP, H.263 Video, G.723 Audio,
and Media Stream Engine) these multimedia components manage the audio and
video functionality in NetMeeting.
Data Conferencing Components (T. 120 data, and built-in data applications) these
data conferencing components handle the transmission of data among different
conference participants. This includes file transfer, application sharing, whiteboard,
and chat data, as well as applications written using the NetMeeting SDK's Data
Channel.


I 1 I
I~r~l~mCl~d~ I



OC~-UI O
n n n n n









*Internet Locator Service Component the Internet Locator Service server

component, communicates with Internet Locator Service on the network to get

directory listings and find users.



Evaluation

The major disadvantage of the NetMeeting SDK is that NetMeeting is a server-

centric architecture, and the SDK does not allow one to directly modify the server or the

environment. Therefore, developers using NetMeeting SDK are limited to designing

NetMeeting clients that rely on a fixed network structure.



Java Shared Data Toolkit

In this section Sun's Java Shared Data Toolkit (JSDT) [14] is described. The

description includes the goal for JSDT, its architecture, and features.



Overview

JSDT is designed to support highly interactive, collaborative applications written

in the Java programming language [4]. It implements a multipoint data delivery service

for use in collaborative, multimedia applications. It also provides the basic abstraction of

a session, and supports full-duplex, multipoint communication among an arbitrary

number of connected application entities over a variety of different types of networks.

Additionally, the toolkit provides efficient support of multicast message communications.

This is accomplished by way of a single send method, and allows the user to define

whether or not a uniformly sequenced reception of data at all receiving locations is

required. A unique feature of the JSDT is the ability to create shared byte arrays whose









values can be set or retrieved by any of the session members. To facilitate

synchronization and floor control, a token-based distributed mechanism is provided. This

mechanism can be used to ensure mutually exclusive access to a resource, to perform

distributed, multi-application atomic signaling, etc. The JSDT as a whole can be used to

help develop any collaborative application that needs to share data among two or more

collaborators.



Evaluation

Like Habanero, the JSDT was designed to be as general as possible. As such it is

not optimized for any specific type of collaborative environment or applications. JSDT

architecture is server centric and requires a server to support a session.



API's Comparisons

Table 1 presents a summary of the characteristics of current APIs.


Table 1- Comparison of Habanero, NetMeeting,

Version 2.0


and JSDT.

3.0 2.0


Company NCSA' Microsoft Sun Microsystems
Architecture Centralized Centralized Centralized
client/server client/server client/server
Product type Research Commercial Commercial
Price Free Free Free
Environment Yes, modifiable Yes, fixed No
Language Java C Java
Supported Platforms All6 Windows All6


5 National Center for Supercomputing Applications at the University of Illinois at
Urbana-Champaign
6 Provided the platform supports Java 1.1


I














CHAPTER 3
ARCHITECTURE FOR AD-HOC WIRELESS COLLABORATION



The previous chapter described the terminology associated with collaboration. It

also evaluated several scenarios for implementing collaborative systems, as well as some

of the existing collaborative APIs. This chapter will concentrate on defining a suitable

architecture for mobile collaboration. As mentioned earlier, the mobile environment

introduces several issues that do not exist in a fixed-network environment. In the next

section, several key technological issues pertinent to mobile devices will be discussed.




Characteristics of the Mobile Environment

The ability to be mobile appeals to the user but presents a great challenge to the

software developer since the environment of a mobile device can differ vastly from that

of a stationary device. The mobile environment is distinguished from a standard, fixed-

connection environment due to the mobility of nomadic users and their computers, and

the mobility of the resources [19, 35, 36]. While most fixed-location devices have the

luxury of consistent and abundant resource supplies such as electricity, processor power,

memory, and network connectivity, mobile devices have no such guarantees.

Compounding the problem, differences among mobile devices range significantly, and as

the current market stands, devices currently produced contain an array of processor

architectures and I/O devices resulting from both environmental influences and market









considerations. Mobility poses new challenges to the application developer, forcing new

techniques to be used to solve these problems.



Bandwidth and Latency

Stationary devices that are wired to a network, either by Ethernet or a similar

protocol, have access to high-bandwidth, reliable connection in which data loss and

disconnection is limited. Wired networks also have a tendency to be more consistent in

delivering bandwidth to the applications. On the other hand, network connectivity of

mobile devices depends on Radio Frequency (RF) technologies to transmit and receive

data. Wireless networks generally exhibit the following characteristics: low bandwidth,

high latency, and high packet loss rate [5]. Wireless connections are continually

bombarded with interference from other appliances such as cellular phones, microwaves,

atmospheric conditions, etc., leading to inconsistent and unreliable bandwidth. In

addition, the configuration of the terrain can have a great effect on the performance of a

wireless connection. The office environment populated with interfering devices as well

as other man-made obstacles such as walls, will provide a different environment from the

wide-open spaces of farmlands. Since the bandwidth varies widely from location to

location and device to device, software developed for hand-held devices must incorporate

fault tolerant protocols.



Processor Power

Processor power becomes critical when dealing with portable devices. Since the

idea behind portable devices is the portability factor, the size of the unit must be kept at a

minimum. As a general rule, the more powerful the processor, the more power it









consumes, and with power already a scarce commodity, mobile devices cannot afford the

cost of a faster processor. It becomes a tradeoff between battery life and a powerful

processor.

Processor power becomes a limited resource, as mobile devices are designed to be

portable and the weight and size of the system must be kept to a minimum. Processor

power and architecture also varies greatly from device to device. Smaller devices extend

operational time by restricting the use of powerful processors. A number of processors

are currently in the market including the 32-bit ARM710T RISC used by the Psion Series

5mx, Intel SA-1100 StrongARM 190MHz used by the Psion netBook [33], and the NEC

VR4111 MIPS processor used by the Vadem ClioTM [7]. Software developed for such

limited systems accommodates low-power processors by implementing a subset of

features usually found in stationary devices. Many new operating systems optimized to

run on a resource limited device currently used in industry are as heterogeneous as the

number of architectures used. The diversity of the operating systems (OS) on the market

now presents a challenge to the software developer. Some of the major players include

3Com's PalmTM OS [32], Microsoft's Windows CE [42], and the EPOC operating system

from Symbian [39]. Although portable devices a few years ago had no provisions for

networking, the operating systems and devices of the future consider this a core

requirement due to the proliferation of the Internet services such as e-mail, the web, and

instant messaging. This requirement leads to other issues such as availability of the

network, bandwidth, and reliability of the connection.









Display Size

Graphical User Interface (GUI) management is also a core requirement, however

with the diversity of display sizes and shapes, this presents a challenge to the software

developer in both accommodating the variations and effective usage of the relatively

small interface. While the size of the display is also an issue in the desktop environment,

it presents less of a problem because of agreed-upon standard resolutions that exist in that

environment. In addition, most of the default resolutions have similar aspect ratios

making it relatively easy to adapt an application to a different resolution. For example,

developers that are targeting an application toward the VGA or SVGA standard can be

assured that the application will retain its intended look on any platform conforming to

the VGA or SVGA standard. On the other hand, the wireless environment is populated

with devices of varying display size. Due to the relative newness of the field, no

standards for display size have been established. Smaller devices such as PalmPilotTM

use low-resolution, monochrome liquid crystal display (LCD) screens (as seen in Figure

6) to both extend battery life and reduce cost, while larger devices such as the Vadem

ClioTM are more powerful and are able to display a desktop at 640X480 pixels in 8-bit

color. As with varying bandwidth, software must adapt to the wide variety of screen

sizes and shapes.



Battery Life

The power necessary for operation, easily obtainable and virtually limitless in a

stationary device, is a scarce resource for most mobile devices. Although some mobile

devices such as those used in automobiles have access to an unlimited supply of power,









most require an onboard power source. Incorporating a power source currently requires

either a Nickel Metal Hydride (NiMH) or Lithium-Ion battery, and while advances in

technologies to increase power and size-reduction in portable power supplies may be

many years away, power management through software and hardware can be used to

compensate for these shortcomings. Hardware and software implementations of power

management must work concurrently to increase the operational time of the device.

Upgraded power supplies tend to compromise the weight and portability of the system,

and as applications become more robust and feature laden, processing power must scale

to the same performance level requiring an upgraded power source. Upgraded power

sources tend to compromise the weight and portability of the system thus limiting the use

of power-hungry, high-performance processors.



Input Methods

Devices of different sizes require different input methods. The possible methods

of data input currently available on the market include keyboard, pen-based, and voice.

Some devices support varying combination of these methods to give the user the most

flexibility [11]. An application must be aware of all the input methods available and

determine which is most efficient or preferred by the user. Fortunately, some of these

input methods operate in a similar manner. For example, a pen based, touch screen, and

mouse-based device all operate on the principle of a pointer. By taking advantage of the

similarities, the application can make effective use of each input device.









Keyboard

A keyboard is the most commonly used input device in the desktop environment.

While it works very well in that particular setting, the most limiting factor for adapting it

to a mobile environment is its form factor. Attempts have been made to miniaturize

keyboards, but in the majority of cases the results are less then satisfactory. The

keyboard is one of the devices that does not scale well. However, its main advantage is

that the majority of users are already familiar with its operation, and can efficiently enter

data without extensive training. Keyboards have their place in the mobile environment,

but they are only suitable for large form-factor devices such as laptops. Anything smaller

than that, especially handheld devices such as the PalmPilotTM and others, must abandon

the idea of using a keyboard as a viable means of entering data, and use alternative

methods that are more appropriate for a small scale device [9].



Pen

Pen based and touch screen input methods are more plausible for handheld,

PalmPilotTM-sized devices, a measuring 5"x3"x0.75" (see Figure 6). With pen-based

input handwriting, recognition software is needed to make data entry efficient and less

cumbersome. As with speech recognition, handwriting recognition is far from being

perfect.



















Figure 6 PalmPilotTM.



The PalmPilotTM, for example, requires the user to adapt his style of writing for

the software to recognize the data. This unnatural style of writing discourages potential

users and makes the data entry less efficient. Other devices, such as the Vadem ClioTM,

have no such restrictions in their handwriting style, but accuracy is much lower. Until

faster and more accurate algorithms or faster processors are developed for handwriting

recognition on mobile devices, keyboard data entry may be the preferred input method.

Devices such as the Vadem ClioTM, measuring 8.75"xll.25"xl", and Psion Series 5mx,

measuring 6.7"x3.5"x0.9", have the necessary real estate to include a usable keyboard

along with pen-based input methods, giving the user a choice.



Voice

Speech recognition is a relative newcomer to the mobile environment. While it

certainly is the most natural way of entering data, speech recognition is still in its infancy

and far from being perfect. One of the main reasons for this is that speech recognition

requires significant processing power, something yet to be found in mobile devices. In

addition, current speech recognition technologies rely on the user training the software to

be able to recognize that particular user's voice, making that device usable only by that









particular user. Today's PC-based programs work by creating a database of recorded

words. That requires extensive storage, not to mention a powerful process to parse the

vocal stream and match words. Currently, 266MHz is the minimum speed for effective

speech recognition on the desktop. Thus, most speech recognition solutions found in

currently available devices are limited to a few simple commands that can be used to

operate the devices, but is too limited to provide a viable means of entering data.




De-centralized Control

A collaborative system can be implemented in two ways: as a centralized system,

or a de-centralized one. In a centralized system one of the hosts is designated as the

central point of the group, and is usually referred to as the server. All other hosts are

referred to as clients and must connect to the server in order to participate in a session.

While direct communication between clients is possible, all communication should pass

through the server in order for the session to be fully synchronized.

A decentralized system does not have a particular host designated as a dedicated

server. All hosts are considered to be equal. Such design provides several advantages.

Eliminating the server eliminates a single point of failure and therefore increases the fault

tolerance of the system (see section Fault Tolerance). The issue with such a distributed

system is assuring that the replicated data is synchronized. A mobile distributed system

must also ensure that the data is available since the location of the hosts is constantly

changing along with the connections between those hosts [19].









Proxyless

To improve the performance of the system, several solutions designed for a

mobile environment utilize the notion of a proxy. A proxy acts as a filter, through which

all messages pass. In most cases it is transparent to the user it appears to the user as

though he is directly communicating with the client, when in fact all requests are directed

to the proxy and the proxy communicates with the server on behalf of the client [15].

The advantage of using a proxy is that a generic application can be developed, that

always produces the same output. However, depending on the type of client sending the

request, the output can be formatted to that specific device. This greatly simplifies

development, because with a proxy existing applications can be used in a mobile

environment consisting of a variety of devices. An example of using a proxy to design a

wireless application is the WebExpress project [13]. However, the proxy is not without

drawbacks. It requires additional processing power, since the proxy must reside

somewhere. In most cases it is located on the server side. However, with a distributed

system there is no fixed server, and that makes establishing a proxy into a challenging

issue. A proxy could be placed on each client, but that increases both the system's

complexity and resource requirements. Therefore, the proxy approach is not a feasible

solution for a distributed collaborative system.



Fault Tolerance

Fault tolerance refers to the ability of a system to work despite unforeseen

hardware and software failures. Centralized systems have low fault-tolerance, because if

the server is disconnected from the session the session cannot continue. The server in

this case is considered a single point of failure. While centralized architecture works well









in a fixed environment, the characteristics of a mobile environment prevent it from being

a viable option.



Ad-hoc Mobility

One of the important features of a collaborative framework is that it must support

the biggest advantage of a mobile environment mobility. Mobility results in another

phenomenon of a mobile environment ad-hoc networks [12]. With an ad-hoc network,

the fixed hierarchy of hosts that exists in a fixed environment gives way to a non-

permanent, impromptu network, often having a flat hierarchy. Ad-hoc networks are

usually set up for a specific, but temporary, task. Once the task is completed the network

dissolves [30]. The ad-hoc network is usually in a very dynamic state, where hosts can

join or leave the network at any time.




Message Based

The architecture for mobile collaboration proposed in this thesis is message-

based. This means that all participants exchange messages that contain instructions

and/or data that is used by each client to reproduce actions performed by the client from

which the action originated.



Transport Layer

Transport layer refers to the underlying protocol that is used for communication

between the hosts. The IP layer supports two major protocols: Transport Connection

Protocol (TCP) and User Datagram Protocol (UDP).











User Datagram Protocol

The User Datagram Protocol is a simple, datagram oriented, transport layer

protocol [38]. Datagram packets are used to implement a connectionless packet delivery

service. Each message is routed from one machine to another based solely on

information contained within that packet. Multiple packets sent from one machine to

another might be routed differently, and might arrive in any order.

There is a limit to the maximum size of a datagram packet. Theoretically this

limit is 64KB and is imposed by the 16-bit total length field of the IP header [38],

although currently no operating system supports such packets. On average, currently

available systems support packets ranging from 4KB to 32KB. In addition, some systems

also provide facilities for adjusting the size of IP packets.

The main advantages of UDP for collaborative systems are its small packet size

(as compared to TCP packets), its connection-less protocol, and the support for packet

broadcast. The main disadvantage is its lack of reliability. The delivery of UDP packets

and the order in which they arrive is not guaranteed, although the UDP checksum ensures

correct delivery.



Multicast

Multicast refers to the process of delivering data to a set of hosts that belong to a

multicast group [38]. This has an advantage in situations that require propagating the

same data to several hosts, and therefore is very suitable for collaborative systems, where

each user's action must be simultaneously delivered to multiple clients. The only

drawback of multicast is that it is based on the UDP protocol and therefore the delivery of









packets is not guaranteed, although efforts have been made to provide reliable, yet

lightweight multicast protocol [18, 23].

Multicast is a natural extension of broadcast and works on a principle that each

client interested in receiving multicast packets joins a specific multicast group. When a

client subscribes to a multicast group and port combination, it receives datagram packets

sent by other hosts to the same group/port, as do all other members of the group and port

(within the time-to-live range of the packet). Clients may subscribe to several multicast

groups concurrently, in which case they will all receive datagram packets from all

groups. The sending host does not need to be a member of the multicast group to send

messages to it.

A multicast group is specified by a class D IP address and by a standard UDP port

number. Class D IP addresses are in the range 224.0.0.0 to 239.255.255.255, inclusive.

The address 224.0.0.0 is reserved and should not be used.

Java's networking package has full support for multicast in Java applications,

although applets are not allowed to use multicast sockets.



Event Replication and Synchronization

With a message-based system, two important issues are the propagation of events

and the synchronization of messages. Synchronization must be enforced in order to

preserve the total ordering of messages. All clients must receive messages in the same

order, or must at least act on the messages in the same order.









Support for Decentralized Control

One of the main features of a mobile, ad-hoc collaborative system is that the

duties of maintaining the session space are distributed among the session participants.

Therefore, unlike collaborative systems designed for a fixed environment, mobile

systems must include provisions for decentralized control that is as transparent to the end

user as possible. After all, no user wants to be burdened with managing the session,

especially if such a task can be accomplished with minimal user intervention.



Bandwidth Requirements

Any system designed for the mobile environment must be aware of bandwidth

constraints. In addition to limited bandwidth, clients might also expect high latency

networks. The system should try to minimize the amount of data needed to accomplish

required tasks.



Ordering of Messages

The ordering of messages is ensured by the event replication mechanism as

described in section Event Replication and Synchronization. In some instances the

underlying hardware aids in the replication process, by providing built-in synchronization

mechanism.




Ad-hoc Networking

This section deals with issues related to the networking infrastructure required for

a mobile ad-hoc environment.











IEEE 802.11 Ad-hoc Networking

Collaboration in a mobile environment is dependent on network availability. In a

fixed environment the presence of the network is so prominent that frequently there is no

need to worry about it. When designing a collaborative system for a fixed network the

designers can count on substantial bandwidth available, but most importantly they can

count on the resources being always available and on the fixed location of the clients.

Ad-hoc collaboration differs from that scenario in that it assumes no fixed

infrastructure to support network communication. As a result, collaborative sessions can

be created virtually anywhere and anytime. This implies that the range of available

hardware limits the range of the group. In most cases this range is up to a few hundred

yards depending on the configuration of the environment (office, field, etc). While this is

a great advantage, it comes at a high cost. Due to the dynamic nature of the network with

clients joining and leaving the session at any time, the availability of resources is very

dynamic and cannot be predicted with the same certainty as in a fixed network.

The IEEE 802.11 standard for wireless networks has several unique features that

make it suitable for an ad-hoc environment [8]. The support for broadcast and multicast

capabilities that is specified in the standard, is very useful in designing collaborative

systems. In such systems there is frequently a need to deliver information to several

clients simultaneously. The multicast protocol makes this possible. In addition, the

802.11 standard specifies collision avoidance protocols. Therefore when one of the

devices is transmitting, no other devices can transmit at the same time. While this might

seem like a serious issue for networks consisting of a large amount of clients (tens of

collaborators), its impact is not felt in smaller groups (up to 15 collaborators). The









multicast capabilities combined with the collision avoidance protocol result in messages

being ordered exactly the same on all clients. This fact is especially important in

collaborative systems, in which the order of the events must be preserved in order to

maintain the consistent state of the session.



Private Networking

Private networking is a scheme that uses a range of IP addresses that are non-

routable, and therefore works well for small groups of computers that need to be isolated

from the outside world [16].



Routing

Current ad-hoc networking standards do not support routing. Therefore all

devices must be within range of each other in order to be able to communicate. Ad-hoc

routing can extend the range of an ad-hoc group. Normally, if client A tries to

communicate with client C, both devices must be within range of each other. If they are

outside the range, communication is not possible. Ad-hoc routing allows another client

(client B) that is in range of both clients A and C to act as a communication relay. Client

C could then communicate with client A, using services provided by client B. This

situation is shown in Figure 7.














IA








Figure 7 Ad-hoc routing. (left) Ad-hoc routing is not available; therefore client A
cannot communicate with client C. (right) With ad-hoc routing, client A can
communicate with client C through client B.



While efforts have been made in the direction of ad-hoc networking [25, 34] at

the present time, no commercial working solution exists. However, one can imagine that

any solution designed for ad-hoc systems should have no problems working in an ad-hoc

environment that has ad-hoc routing implemented.



Naming Conflict Resolution

Another issue is resolving the conflict between clients' names, on the physical

layer. This issue is automatically handled by the networking hardware, and no special

action is required from the user.




Recovery

This section deals with issues related to the recovery of the state in ad-hoc

collaborative systems. The recovery issue is of much greater importance in the mobile

environment, due to the poor reliability of the environment itself. As mentioned before,









one way to deal with poor reliability is to eliminate single points of failure and implement

a de-centralized system. However, such systems have their own issues such as a need for

a dynamic session coordinator, and preservation of the state of the session.



Leader Election

Leader Election refers to a process by which a group of clients elect a session

coordinator, also known as a session leader, based on some previously agreed upon rules.

Typically, collaborative systems designate one of the participants as the entity

responsible for coordinating the session. In most cases the coordinator resides on the

central server. In the mobile ad-hoc environment, the session must be prepared to deal

with the loss of the coordinator, and must continue its progress even when the

coordinator suddenly becomes unavailable. In order to accomplish this, dynamic ad-hoc

groups usually specify a set of rules that are used to dynamically elect a leader, in the

event of loss of the session coordinator. Several well-know algorithms exist that can be

used for this purpose. One of the most widely known is the bully algorithm, which is

based on a unique ranking number assigned to each client. The leader election process

should also be as transparent as possible, and should require minimal user intervention.



Session State

In the typical fixed environment, the state of the session resides on the fixed

server since it is usually the one with most resources. The session state in this case refers

to the information that is needed to bring a new client up to the state of the session at a

particular point in time. This ability is of even greater importance in the mobile

environment in which client disconnections are much more frequent than in a fixed






48


environment. Also, since mobile clients have to deal with resource limitations, care must

be taken to ensure that the process of preserving the session state occupies the minimum

amount of resources. A decentralized system must be able to reliably preserve the state

of the session on multiple clients, and at the same time be able to efficiently restore state

information.














CHAPTER 4
YCAB SERVICES




Services

This chapter describes the services that are included in the YCab API. These

services are divided into two groups: required services, and optional services. The

required services are an intrinsic part of the YCab environment and are always included

in the client. These services and their operation are for the most part transparent to the

user. The optional services are services that are not required for the YCab client to

function properly. These modules provide additional functionality and can be used to

design custom applications.

In this chapter the description of each service is divided into two parts: the

Description and Usage section, and the Implementation section. The Description and

Usage section describes the service, its purpose and the default user interface, if any. In

addition, it provides an overview of the service's functionality and its operation. The

Implementation section assumes that the reader is already familiar with the Description

and Usage section, and provides insights regarding how the particular service was

designed using the YCab API. All screenshots of the services are taken from a sample

session conducted with the YCab application that is included in the API. The screenshots

are a good indication of the appearance of each service. However, each service's









appearance might change when it is resized or used in other application. Regardless of

the application, the basic functionality of a service will remain the same.



Leader Election Service

The Leader Election service is a required service that provides the implementation

of the leader election protocol. This service performs the process required to elect a

session coordinator.



Description and Usage

This service does not implement any custom GUI components, and therefore the

user does not have any control over the execution of this service.



Implementation

Since the Leader Election service is an integral part of the YCab framework,

there was great flexibility in designing the architectural layout of this service. The

Leader Election is ultimately implemented as a ThreadedService since YCab already

includes facilities for communication and message routing. During a normal

collaboration session, the election process must not interfere with the operation of any

other services. This requires the Leader Election service to contain its own thread of

execution. In most cases, the election process is transparent to most services as well as to

the user.

Unlike other services that do not implement framework protocols, the Leader

Election service is automatically instantiated and registered with the Client Manager. By









doing so, the YCab framework is guaranteed to have a leader election voting mechanism

available during the handshake process as well as during regular session operation.



Session Manager Service

The Session Manager Service is a required service that cooperates with the Client

Manager to provide session management services.



Description and Usage

This service does not implement any window components, but has two custom

menus: Set as Coordinator, and State Recovery.

Set as Coordinator enables/disables the current client as session coordinator.

This toggle menu can be used to designate the current client as the session

coordinator. When this menu is selected, a checkmark appears next to it,

which indicates that the client is indeed the session coordinator. Selecting this

menu again causes the current client to become a regular session participant.

State Recovery initiates state recovery. Selecting this menu initiates the

state recovery process in which the client tries to retrieve session's state

information, so that the state of the client is consistent with the state of the

session. This is achieved by recovering the session's state information for

each of its services. Upon selection of this menu, the client will switch into

state recovery mode as indicated by the status indicator of the Client Info

service (section Client Info Service). While in this mode the client will not

process new messages until all state recovery data has been received.

Depending on the connection speed and the state of the session, the state









recovery process might take anywhere from just a few seconds to over a

minute. While in the state recovery mode the client responds to user's input

and propagates user's action to other clients, although the results of those

actions are not visible to the client itself until the state recovery process is

finished. The session coordinator cannot perform state recovery on itself, and

therefore this menu does not have any effect if the current client is already the

session coordinator.



Implementation

The Session Manager service contains core logic associated with session

management. Some of its main responsibilities include providing the handshaking

mechanism for joining and leaving the session. Although much of the logic is controlled

in Session Manager service, most of the code resides in other classes. This service

merely invokes and controls them. Session Manager service also maintains a hash table

of peers that is available for use by other services. Since this class is implemented as a

regular service, it communicates with other clients the same way other services do,

through messages routed by the Message Router. Unlike other services, this is a required

service that cannot be removed from the framework, thus it is automatically instantiated

and registered within the Client Manager.

The handshake procedure occurs in two phases. First, the new client must join the

session. Once the client successfully joins the session, the second phase performs state

recovery on the new session member. Finally, when a client is leaving the session, the

leave session protocol is performed.









This class also provides synchronized methods that allow threads to monitor the

peers Hashtable for changes. The getNotifiedPeers () method causes threads to

wait until notified by a thread that is making changes to the peers list. Changes to the list

should be made through the addToPeers () and removeFromPeers () methods.

These methods notify a thread waiting on this monitor.



Session Ping Service

The Session Ping service is an optional service that provides pinging services for

discovery of clients in the session.



Description and Usage

The pinging of session members occurs in the background and as such does not

require a lot of input from the user. Although Session Ping service does not contain a

panel interface, the service provides a custom menu that is used to control the execution

of this service. If the service is stopped manually through the menu, Session Ping service

will no longer respond to ping requests from other clients. As a result, other members in

the session will subsequently remove this client from their respective peers list, resulting

in inconsistent session data. Certain services such as GPS service rely on the peers list to

operate correctly, so disabling the Session Ping service may adversely affect other

services.



Implementation

Session Ping service is an optional service that implements the Threaded Service

interface. During normal operations, an internal ping request thread periodically sends









out a ping request (Protocol. PING_REQUEST) message and then proceeds to sleep

for a specified period of time. After the timeout period, the thread checks the responses

to determine which clients to remove and which clients to add. This process runs

indefinitely or until the user manually stops the service. While the ping request thread is

sleeping, another internal thread processes incoming messages. If the incoming message

is of type Protocol. PING_REQUEST, then a response message of type

Protocol. PING_REPLY is sent out. Otherwise the message is assumed to be a 'Ping

Response' and is subsequently stored. The ping request thread uses the stored responses

when it awakens.

Session Ping service pings session members and dynamically adds or removes

them from the peers list. It is threaded, so this process takes place in the background. A

ping request message is sent out at certain intervals. Those clients that receive the ping

request send a ping reply message. The reply messages are locally stored in a Hashtable.

The Hashtable is then compared to the peers list in the Session Manager service to check

for inconsistencies. If a name from the Session Manager service peers list is not

contained locally, then we assume the client is either in State Recovery mode (unable to

respond to the ping request) or the client has left the session. To distinguish between

these two, the service examines the previous ping cycle and checks the history. If the

missing client is present in the previous cycle, then the name is kept in the Session

Manager service peers list. If the missing client was also missing in the previous ping

cycle, the client is then removed from the Session Manager service peers list. A client

can also be added to the peers list if it was inadvertently removed. To check for this, the

service checks the history of both the locally stored list and the Session Manager service









list. If a client is present locally in the last ping cycle and the present ping cycle, then the

service checks to see if that client name exists in the previous Session Manager service

derived list, but not the current one. If this is the case, the client name is added the

Session Manager service list.



Text Chat Service

This service is an optional service that implements a simple text chat service. A

text chat service enables one to send text messages to other session participant. The GUI

of the Text Chat service is shown in Figure 8.

Dan: Hello
Stephanie: Hi
Dominik: Hey, what's up?
Dan: No much
Stephanie: Same here




Cool picture! Send


Figure 8 User interface of Text Chat service.



Description and Usage

The service GUI consists of three main components as shown in Figure 8. The

majority of the service's area is occupied by the dialog window, which contains the

dialog between users. The text in the dialog window cannot be edited. Immediately

below the text window is a text field that is used to type messages to be sent to other









users. Next to the field is a button labeled 'Send' that is used to send the contents of the

field.

The operation of the Text Chat service is very simple. To send a message, the

user enters the desired text in the text field. As long as the text appears in the text field, it

is not seen by other users, and can be modified if desired. To send the message, the

collaborator clicks on the 'Send' button. After a short delay dependent on the connection

speed the message should appear in the dialog window. At the same time, the text field is

cleared and made ready to accept more messages. An alternative way of sending a

message is to press the 'Enter' key on the keyboard (if a keyboard is available). This

action is equivalent to pressing the 'Send' button and is included for convenience. Each

message is preceded with the name of the client that sent the message. The order of

messages is preserved and the most recent messages are added at the bottom of the dialog

window. When the dialog window becomes completely filled, new messages will also be

added on a separate line at the bottom and the content of the window will be

automatically scrolled to display the new message. If the need arises to review past

messages, the vertical scrollbar located at the edges of the dialog window can be used to

scroll the dialog. Similarly, the horizontal scrollbar can be used to read lines of text that

do not fit completely on the screen since the service does not automatically wrap the text.

Each message sent from the Text Chat service will be seen by all users participating in

the session. At the present time there is no facility that allows sending of private

messages to a specific user.









Implementation

The implementation of the Text Chat service is simple. The service implements

the init () and processMessage () methods as required by the Service interface.

The init () method defines the window components for this service. No service-

specific menus are associated with this service. The processMessage () method

assumes that all incoming messages are of the same type and contain data of type String.

The name of the sender is extracted from the header and appended to the data, which is

then displayed in the dialog window. To facilitate user interaction the Text Chat service

implements both ActionListener and KeyListener. This way, clicking on 'Send' button is

equivalent to hitting the 'Enter' key on the keyboard. Upon receiving the event from the

'Send' button, the text from the text field is acquired and is send to all session

participants. All messages originating from this service are marked as data messages

(Protocol. DATAMESSAGE). The service does not implement a custom state

recovery mechanism since the default one is sufficient due to the fact that all messages

are of the same type and can be easily enabled with this service. This service does not

implement any optimization modes.



Whiteboard Service

This optional service implements a shared whiteboard. The Whiteboard service

provides a shared drawing surface that is used to visually exchange information with

other session participants. The GUI of the Whiteboard service is shown in Figure 9.





























':lear Blac.: FIeel-halnr


Figure 9 User interface for the Whiteboard service.





Description and Usage

The Whiteboard service provides collaborators with a common drawing area. The

GUI, as shown in Figure 9, is divided in two parts. The majority of the screen is

occupied by the white drawing area. This is the area in which the collaborators can draw

images. At the bottom of the service are three components. The 'Clear' button provides

functionality for erasing the contents of the whiteboard. The pull-down list located to the

right of the 'Clear' button allows the collaborator to select a drawing color. The menu

provides 12 pre-defined colors. To the right of the list is another pull-down list

containing available shapes that can be drawn on the whiteboard. The following items

can be selected: Freehand, Line, Rectangle, Oval, and Erase.









The main purpose of this service is to provide facilities for drawing. The general

concept is to select a color, select a shape, and then using a mouse, pen, or other pointing

device, draw the desired shape on the whiteboard. The procedure varies slightly for

different shapes, as described below. In addition, the exact procedure will also vary

depending on the specified optimization mode as described later in this section. This

section assumes that the optimization is not enabled in which case the service exhibits the

default behavior.



Clearing the Whiteboard

To clear the drawing surface of the whiteboard, the button labeled 'Clear' is

selected. Only the Session Coordinator has permissions to clear the whiteboard. Any

request to clear the whiteboard originating from a collaborator other than the session

coordinator will be ignored. This is due to the fact that the 'Clear' button clears not only

the local drawing surface, but also the drawing surface of other clients.



Selecting the Color

The drawing color is selected by clicking on the pull-down list located to the right

of the 'Clear' button. The list should expand to reveal a list containing 12 colors: Black,

Blue, Cyan, Dark Gray, Gray, Green, Light Gray, Magenta, Orange, Red, White, and

Yellow (in that order). On some systems the collaborator might have to scroll through

the list in order to see all the available colors. Selecting any of these colors indicates that

all drawing originating from this client will appear in the chosen color. The color does









not affect the color of shapes drawn by other collaborators, and conversely, any shapes

drawn by other collaborators do not affect the local color selection.



Selecting the Shape

The procedure for selecting a drawing shape is similar to the procedure for

selecting the color. To select the drawing shape the collaborator clicks on the pull-down

list that is located to the right of the pull-down list used for selecting the color. The list

should expand to reveal a list containing names of five pre-defined shapes: Freehand,

Line, Rectangle, Oval, and Erase. Selecting any of these shapes indicates that all drawing

originating from this client will have the selected appearance. The shape selection does

not affect the shape chosen by other collaborators, and conversely, any shapes drawn by

other collaborators do not affect the local shape selection.



Drawing Shapes

The shapes are drawn on the whiteboard using mouse, pen, or other pointing

device. This section assumes that a mouse containing at least one button is used. To

draw a shape, the collaborator first selects the color and the shape (see sections Selecting

the Color and Selecting the Shape) and points to the starting location for the shape. As

the collaborator moves the mouse around the whiteboard the shape is being drawn on the

screen. However, the shape does not appear in the selected color, but instead is drawn in

pink color. This indicates that the data used to describe the appearance of the shape is

collected, but other collaborators will not see the shape until the mouse button is released.

Once the shape has the intended appearance, the collaborator releases the mouse button









and the shape is propagated to all session participants. At this point the color of the shape

should change to the desired color. If the color of the shape remains the same, it

indicates that a problem occurred in processing the collaborator's action. As a result, the

shape was not propagated to all session participants. At the present time there is no way

to cancel the collaborator's action once the user had started drawing the shape. It should

also be noted that once a shape has been drawn, its attributes such as color, size, and

location cannot be modified. Additionally, all collaborators' actions originating from the

Whiteboard service are always sent to all session participants there is no way to specify

a single receiver. Below is a brief description of each available shape.

Freehand allows freehand drawing on the whiteboard, ie. the shape will

appear exactly as it is drawn.

Line provides facilities for drawing straight lines. The first click indicates

the start of the line. Moving the mouse around allows the collaborator to

specify the end-point. The line represents the shortest distance between the

start point and the end point.

Rectangle provides facilities for drawing unfilled rectangles (rectangular

outlines). The first click indicates the upper left corner of the rectangle.

Moving the mouse around allows the collaborator to change the width and the

height of the rectangle. Due to system limitations it is not possible go to the

left and up from the starting location.

Oval provides facilities for drawing unfilled ovals (circular outlines). The

fist click indicates the upper left corner for the oval (when bounded by a

rectangle). Moving the mouse around allows the collaborator to change the









width and the height of the oval. Due to system limitations it is not possible

to go to the left and up from the starting location.

Erase provides erase functionality. This is similar to the Rectangle

functionality except that the area bounded by the specified rectangle will be

cleared, by setting the area to the background color.

In addition, the whiteboard implements two optimization modes, which can be

enabled by the developer. The default optimization mode is the high-bandwidth mode in

which updates are only propagated upon the release of the mouse button, as described

above. In real-time mode, everything that is drawn on the screen is immediately

propagated to all session participants. This includes the drawing and resizing of

rectangles, ovals, etc. This mode is most useful for freehand drawing and only when very

high-speed connection is available. The low-bandwidth-mode is not implemented and

has the same behavior as the high-bandwidth mode.



Implementation

The Whiteboard service implements the Service interface and as such implements

the init () and processMessage () methods. The init () method defines the

GUI for the service. The Whiteboard service is implemented with a custom component

DrawPad that provides the drawing surface for the service, and actually performs the

drawing of the shapes. The DrawPad object extends Java's Canvas class and inherits that

class's behavior. The Whiteboard service provides encapsulation for the DrawPad

object, and also responds to user interactions and handles the communication with the

framework.









Since the Whiteboard service uses custom window components, it must

implement its own resetServicePanel () method. The custom implementation of

this method ensures that the DrawPad's drawing surface is cleared and is set to the

default background color when invoked. In addition, the Whiteboard service also

implements the state recovery method. This ensures that when the service receives the

clear drawing surface request, it not only clears the drawing area, but also clears the

current state for the service, since the data stored by the State Manager is already

outdated and no longer needed. This optimizes the service so that unnecessary data does

not need to be restored.

The Whiteboard service works by sending a Vector object that describes the shape

to be drawn on the screen. The information contained in the Vector is the color of the

shape and shape's coordinates. Each coordinate consists of two integer values that are

encapsulated in Java's Point class. The Whiteboard service also uses the payload type to

distinguish between different shapes. Based on the value of the payload type, the Vector

of coordinates has differing formats, and is interpreted appropriately. For example, in a

message containing data for a rectangle, the first element of the Vector is the color, the

second element is the starting x and y coordinates, and the final element is the width and

height of the rectangle.

The Whiteboard service implements service optimization. It implements the real-

time mode and the high-bandwidth-mode. In high-bandwidth mode, the service collects

the data used to describe the shape and packages it into the Vector, as the collaborator is

drawing the shape. Once the service detects that the mouse button has been released, it

then sends the entire vector as a single message. In real-time mode, a Vector containing









the coordinate data is sent out immediately after each data point has been collected. The

low-bandwidth mode is not implemented and is equivalent to the high-bandwidth mode.



Image Viewer Service

The Image Viewer service is an optional service used to share local images

among the session members. This service only supports image formats that are platform

independent, namely JPEG and GIF formats.


I-Viewer > ralph.jpg















Figure 10 User interface for the Image Viewer service.



Description and Usage

The Image Viewer service is a shared image viewer. It provides the collaborators

with image viewing capabilities for images of type GIF or JPEG. As can been seen in

Figure 10, the majority of the screen is occupied by the area used to display the image.

Additionally, the top portion of the service shows the name of the image that is currently

being displayed.









Images can be viewed by selecting the Open item from the Image Viewer menu

bar. A system-specific file dialog box will appear. From this dialog box the collaborator

selects any GIF or JPEG image. The selected image will appear in the Image Viewer

service, for all session participants. Any image can be displayed, but the time to send the

image can be substantial if the image is large and the network capabilities are limited.

Therefore, the collaborator sharing the image may experience a significant delay between

selecting the image to share, and the image actually appearing on the screen. If the size

of the displayed image does not fit entirely in the visible area, the scrollbars located to the

right and on the bottom of the service are used to scroll and pan the image. Due to the

size of a typical image this service experiences higher failure rate than other services,

especially on unreliable networks. If a part of the image is lost during transmission, the

image is not displayed, in which case the collaborator must try to display the image

again.

The Clear option in the service's menu bar is used to clear the image from the

session and return the service to its initial state. Selecting this option clears the image on

all clients that are in the session. Only the session coordinator is allowed to clear the

Image Viewer service.

The Restore State option, if enabled, is used to restore the state of the Image

Viewer service. Any image currently shared in the session should appear in the Image

Viewer service when this option is selected. This functionality works in much the same

way as refreshing a web page in a web browser.









Implementation

This optional service implements the Service interface. As such, the Image

Viewer service must as a minimum provide implementations for the init () and the

processMessage () methods. The init () method implements the GUI

components for the service. In this service the main image viewing area is composed of a

ScrollPane object containing a custom Image Panel component. The Image Panel

contains functionality for displaying either JPEG or GIF images from a byte array with

the option of clipping the image to fit a set panel size, or for automatically resizing the

panel to fit the image. Since the Image Panel is contained within a ScrollPane, the Image

Viewer service uses it as a resizable Panel. If a shared image is larger than the available

viewing area, the scroll bars are automatically activated to allow viewing of the entire

image.

All messages sent by the Image Viewer service are marked as data messages

(Protocol. DATA_MESSAGE). In addition, the service uses two different payload

types: image data, and clear request. The message with payload type of image data

contains as its payload the image to be displayed. On the other hand, the message with

payload type clear, instructs the service to reset the service to its initial state. As a result,

the Image Viewer service provides its own implementation of

resetServicePanel () and updateState () methods. The

resetServicePanel () method ensures that when a service is reset, the visible area

of the ScrollPane is also cleared. The custom updateState () method ensures that

only the most recent image that is displayed on the screen is saved by the State Manager.









GPS Service

This optional service provides services for working with GPS devices. It is used

to improve the session awareness by graphically displaying the locations of session

participants. Since no actual GPS device could be obtained, this service simulates GPS

coordinates.

southeastern
DominikUniu Of Health Stephanie
Science *


it-t
m Na 163rd St
= 826

SDan
z Ne 1 3th St
D N
eN Nl15&th S
o w



Figure 11 User interface for the GPS service.



Description and Usage

The GPS service displays the map and the coordinates of all members in the

session as shown in Figure 11. The entire visible area of this service represents the

physical area for the session. When the service is running, the locations of all the clients

are represented on the area by dark dots. In addition, each client is annotated with that

client's name. This way one can quickly determine the client's position in relation to

other session participants. During normal operation, the coordinates for each client are

updated periodically and the GPS service requires no user input since most of its

processing occurs in the background. In addition, the GPS service allows importing

images that represent the terrain in the area as long as they are either in GIF of JPEG









format. Client's locations are then drawn on top on the image that serves as the overlay

for the GPS service.

The GPS service provides two custom menus in order to enhance its functionality:

Open, and Clear. The Open menu is used to load the background image. Selecting this

item will bring up a file dialog window that is dependent on the underlying operating

system. The file dialog window allows the collaborator to browse the local file system

and select the image to be loaded. The GPS service can read any GIF or JPEG image, but

does not implement image scaling, so it is the user's responsibility to ensure that the

selected image fits in the available area.

The Clear option is used to clear the GPS area. It removes all locations that are

currently drawn on the screen as well as the background image, if any, and initializes the

service to its initial state.

The GPS service implements service optimization. If the optimization is enabled,

it can be used to control the frequency of the coordinate updates. The default mode is

high-bandwidth, in which the GPS coordinates are updated every 15 seconds. In low-

bandwidth mode the coordinates are updated every 30 seconds, and in real-time mode the

updates occur in 5-second intervals.

If the service controls are enabled the GPS service can also be stopped and started

at any time. In that case, two choices appear in the service's menu: Start, and Stop. The

service is started automatically when the client connects to a session, but can be stopped

at any time after that. When the GPS service is stopped, the service does not process any

coordinate updates, and at the same time, does not send out its own coordinates. As a

result, the client with a suspended GPS service will appear to be stationary even though









that is not necessarily the case. The service is stopped automatically when the client

leaves the session.



Implementation

The GPS service implements ThreadedService interface. In addition to

implementing the standard init () and processMessage () methods required by

the Service interface, it also implements start () and stop () methods for controlling

its internal thread. The service runs in a continuous loop that acquires client's

coordinates from the GPS device1 and sends them to all session participants. It also

receives GPS coordinates from other participants and displays the results on the screen.

The coordinates are sent as an array containing the values representing the coordinates.

Each coordinate is represented by two integer values the X coordinate, and Y

coordinate.

The GPS service uses custom component ImageGPSGrid that is an extension of

Java's Canvas class. The ImageGPSGrid object provides the drawing surface as well as

displaying area for the images. As a result, GPS service implements its own

resetServicePanel () method which ensures that the service area is cleared when

necessary. The service also implements its own state recovery mechanism by

overwriting the updateState () method. The State Manager only stores the most

recently loaded image and does not retain any coordinates, since the coordinates are

continuously updated and time-dependent the coordinates data becomes invalid after a

certain period. All messages sent by the GPS service are marked as data messages


1 In this case, the service simulates GPS device by generating random coordinates.









(Protocol. DATA_MESSAGE), and the service uses three different payload types:

coordinate data, image data, and clear request, which correspond to messages containing

coordinates, image, and request to initialize the service, respectively.



Client Info Service

Client Info service provides session and state information for the client. It

monitors for any changes to the client and the session, and updates the display

accordingly.


Client Info Service

IP:Port-> 225.5.5.5:4343

Session Members Client Properties
Dominik clientName->Da
Stephanie msgRouterMode
Dan joining->false
inSession->true


StatI is

Currently in session

Figure 12 User interface for the Client Info service.





Description and Usage

The Client Info Service is an optional service that does not provide interaction

with other clients. Instead, its main purpose is to show the session collaborator the state

of the session as well as the state of the client.









The window area provides a wealth of information, as shown in Figure 12. The

top portion of the service displays the name of the service, the IP address, and port

number for the session. These are the values as specified in the Connection Info

Properties dialog window. Two lists occupy the middle of the service's area. The list on

the left-hand side entitled 'Session Members', displays the names of all clients that are

currently in the session. The list is updated as clients enter or leave the session. The list

on the right-hand side entitled 'Client Properties' contains client's properties. This list is

updated as soon as any of the listed properties changes. These properties can be used to

determine the name of the client, and various modes of the client's managers. At the

bottom of the screen resides a status line. This status line displays the status of the client.

The possible values for the status line are as follows:

Currently in session indicates that the client is connected to the session.

You are the Coordinator indicates that the client is in the session and is the

session's coordinator.

Currently in State Recovery indicates that the client is in state recovery

mode. This indicates that either the client has requested state recovery or that

the client is the session coordinator and is in the process or recovering another

client.

Currently in Election indicates that the session participants are currently in

the process of electing a new session coordinator and the client is participating

in the election.









The Client Info service can be stopped and started at any time. If the service

controls are enabled, two choices are available to the user: Start, and Stop. The service is

started automatically when the client connects to a session, but can be stopped at any time

after that. Stopping the service results in the client properties and other information not

being updated. The service is stopped automatically when the client leaves the session.

In addition, the Client Info service provides a menu item that can be used to immediately

update all the properties. Selecting Refresh from the service's menu will rescan client's

properties and update the display accordingly regardless of whether the service is

currently running or not.



Implementation

Since the service requires no input from the user, it is implemented as a non-

interactive ThreadedService. The required init () method is responsible for setting up

the GUI. Since this service neither receives nor sends any messages to other clients, it

does not provide the actual implementation for the processMessage () method. The

threads are used to monitor the properties table in the Client Manager as well as the list of

peers in the Session Manager service. In order to provide control over the internal thread,

the service provides custom implementation of the start () and stop () methods, as

required by the ThreadedService interface. Upon initialization, the Client Info service

queries the Client Manager for a reference to the Session Manager service. If a reference

is returned, then threads are dispatched to monitor the list of peers in the Session

Manager service and the properties table in the Client Manager. Both threads block until

a state change occurs.











Service Summary

Table 2 summarizes the services included in the YCab API, and compares their

features and requirements. The Opt column indicates whether the service implements

optimization. The Req column indicates whether the service is a required service. The

std abbreviation indicates that the service implements standard state recovery mechanism,

while cust indicates custom state recovery mechanism. The rest of the columns are self-

explanatory.




Table 2 Summary of YCab services.


Leader Election


Elects session coordinator


No, N/A


Yes


Session Manager Manages session No Yes No No, N/A Yes

Ping Client discovery No Yes Yes No, N/A No

Text Chat Text-based chat Yes Yes No Yes, std. No

Whiteboard Shared whiteboard Yes Yes Yes Yes, cust. No

Image Viewer Image viewer Yes Yes No Yes, cust. No

GPS Location awareness Yes Yes Yes Yes, cust. No

Client Info Session information Yes Yes No No, N/A No


API Optimizations

When implementing the API, its goals, namely small footprint, portability, and

efficiency, were constantly kept in mind. Those criteria were used to try to optimize the









API without sacrificing its usability. The optimizations can be found on two levels. The

first level is the environment and the API itself. Here a conscious effort has been made to

provide the most functionality in the smallest package. Currently the entire system

occupies about 170KB of memory and can be further reduced by providing compressed

packages or removing services that are not used in a given application. Where network

communication is involved, a substantial effort has been made to transfer as little data as

possible in order to accomplish the required task. These optimizations involve both the

types of objects transferred between the clients, and the optimization of the protocols.

The second level of optimizations stems from the services itself. The Service API

includes provisions for implementing different levels of optimizations. While these

optimizations are not required, the developers are encouraged to use these facilities.














CHAPTER 5
DEVELOPING A CUSTOM SERVICE USING YCAB API




In order to create a custom service one needs to be familiar with how the YCab

environment works, and specifically, the role of the services in the API and how they

interact with the environment. In this section steps necessary to create a custom service

are described. Such service can later be used to implement a collaborative application.

This tutorial will develop a text chat service that has similar functionality to the pre-

defined Text Chat service included in YCab API.

All YCab services must conform to either the Service interface or the Threaded

Service interface in order to be successfully integrated into the environment. The Service

interface allows developers to easily create modules the services that can later be used

to implement a custom collaborative application. The first step in designing a custom

service is importing the service package. Depending on the amount of interaction

between the service and the application, other YCab packages should be imported.

Specifically, the message and the client packages are useful in the development process.

Once the packages have been imported, the next step is to implement the Service

interface. First, the service has to extend the Service class. The Service class is an

abstract class and as such each custom service must, as a minimum, implement two basic

methods: processMessage (), and init ().









The init () method should contain initialization an procedure for the

service. In most cases, this consists of the code for creating GUI components

both window and menu components. The init () method is invoked from

the constructor, and must be invoked only once.

The processMessage () method provides the procedure for dealing with

the incoming messages. The Client Manager invokes this method on the

service, whenever a message is addressed to that particular service. The

method is invoked with one parameter the message to be processed. The

Client Manager guarantees that the object passed as an argument is a complete

message, and it the service's responsibility to process the message.

These requirements result in the service skeleton code as shown in Figure 13.

import service.*;
import client.*;
import message.*;

public class MyService extends Service {

public void init() {

}
public void processMessage(Object message) {



Figure 13 Basic skeleton code for a service.



At this point this service can be instantiated and registered with any YCab

application. However, the service is not very useful, since neither the GUI nor the

message processing mechanism has been implemented. The first step is to implement the

GUI components for this service. The GUI initialization procedure should be placed in









the init () method. All GUI components must conform to Java's Abstract Windowing

Toolkit (AWT) specifications defined by Java 1.1. Therefore, anyone familiar with the

AWT should have no trouble developing a GUI for a service. The Service class has two

objects associated with the GUI components. A Panel object is a container for the

window components that belong to the service. It can be accessed through the variable

named panel. A Menu object is used for keeping the menu components associated with

the service. It can be accessed through the variable named menu. Since both of these

variables are instance variables they can be accessed anywhere, in any class that extends

the Service class. Although standard methods of the Panel and Menultem classes can be

used to manipulate these objects, the Service class provides additional methods for

adding new items to these objects. The methods addComponent () and

addMenuItem (), add an item to the service's panel and the menu bar, respectively. In

addition the addMenuItemSeparator () method can be used to add a separator item

to the service's menu. The default layout manager used by the Service class is the Flow

Layout Manager, although it can be changed if needed. Figure 14 shows sample code

that will create the window GUI and menus for the Text Chat service. At this time, some

of the components have also been registered with the appropriate listeners. This is not

required, but is used to implement a mechanism for interacting with the service, as

explained further in this section.

public void init() {
setPanelLayout(new BorderLayout());
textArea = new TextArea();
textArea.setText ("");
textArea.setEditable(false);
panel.add("Center", textArea);
Panel p = new Panel();
textField = new TextField("", 20);
p.add(textField);









sendButton = new Button("Send");
sendButton.addActionListener(this);
p.add(sendButton);
panel.add("South", p);

MenuItem m = null;
m = new Menultem("Print State");
m.addActionListener(this);
addMenuItem(m);
addMenuItemSeparator( ;

Figure 14 The init () method for the text chat service.



Now that the init () method has been implemented, the next step is to

implement the constructor for the service. At a minimum, the constructor must call the

constructor in the Service class to ensure that the service is properly initialized. The

constructor must also call the init () method. The name of the service is specified as

an argument to the constructor. The constructor must then call the constructor of the

super class (Service class) with that argument, to ensure that the service is initialized

properly. Additionally, the super constructor must be invoked before any other methods

are called in the constructor. If the super constructor is invoked without specifying a

name for the service, the service will be automatically assigned the name "No Name".

The name of a service serves two main purposes. One, the name is used to provide the

title for the menu, if there is one associated with the service. The name also serves as a

unique identifier for each service, and is used by the Message Router to route the

messages. Therefore, it is up to the developer to ensure that each application consists of

services with unique names. Figure 15 contains the code for the new constructor.

public MyService(String serviceName) {
super(serviceName);
init () ;
Figure 15 Constructor code for the text chat service.
Figure 15 Constructor code for the text chat service.









At this point the service has a nice GUI and a custom menu (see Figure 16), but it

actually does nothing. The next step is to implement the sending and receiving of

messages. In order to process incoming messages the service must provide

implementation of the processMessage () method.



t-;1 I-lcI
tH-:1 I-N-1c'














Figure 16 Optimized YCab application with a single service.



The Client Manager invokes this method whenever a new message arrives. The

Message Router examines the header of each message and, based on the information

contained in the header, invokes the processMessage () method on an appropriate

service. The argument to processMessage () is a message of type Object.

Therefore, the first step is to cast the object to an appropriate type. In most cases this will

involve casting the argument to an object of type CoreMessage, since it is the default

message type used for communication among clients. Each CoreMessage object consists

of a header object and a data object. This tutorial assumes that all messages sent and

received by this particular service have the same payload type a String object

containing the text message to be displayed on the screen. Once a message is received by









the service, it is displayed on the screen. However, a service is not restricted to using just

one type of payload. The Payload Type field in the header is used to indicate different

types of payload encapsulated in the message. The getPayload () method in the

CoreMessage class is used to extract the data from the message. This method returns an

object of type Object. Therefore, before the payload can be displayed on the screen, the

returned object must be cast to an object of type String. In addition, the information from

the header, namely the name of the sender, is appended to the text. This text is then

displayed on the screen, inside the TextArea component of the service. Figure 17

contains the code for the processMessage () method.

public void processMessage(Object message) {
CoreMessage cm = (CoreMessage)message;
Object payload = cm.getPayload();
Header header = cm.getHeader();
textArea.append(header.getSenderID()
+ ": + (String)payload + "\n");

Figure 17 Code for the processMessage () method.



The service can now process incoming messages, but it still does not have the

ability to send messages. Since messages are only sent upon the explicit request of a

user, the send functionality is dependent on the component events. Specifically, the

message will be sent when a collaborator clicks on the button labeled 'Send'. The 'Send'

button has already been registered with an appropriate listener in the init () method.

This process follows the standard Java procedure for registering an AWT component

with a listener. Since an AWT component of type Button generates Action Events, the

service must implement the actionPerformed () method. Upon receiving an event,

this method takes the content of the text field and sends it to all the session participants.









The process by which the text from the text field is acquired is fairly easy. A String

object containing the text is returned when the getText () method is invoked on the

text field. In order to send the message, the Service class provides the send () method.

There are five versions of the send method, which differ in the number of arguments.

They all however provide the same functionality, which is, they allow the service to send

the specified data to any clients in the session. The API documentation provides a

complete description of each send () method. For the purposes of this tutorial, the

send () method used by this service takes three arguments. The first argument specifies

the intended receiver for the message. Since the intention is to send this text to every

session participant, one of the pre-defined codes for a receiver field is used. An alternate

way to specify the receiver is to create a String containing the names of all the clients in

the session, but for optimal performance the Protocol class provides a pre-defined code

for sending the messages to all the session participants. In this case, the first argument

will be specified as Protocol .ALL. The second argument specifies the type of the

message. Again, the Protocol class contains predefined types for the different message

types. In most cases, the user-defined services will specify the message type

Protocol. DATA_MESSAGE for all messages that contain data to be propagated

between the clients. Other message types are used for state recovery messages and

implementing the protocols forjoining and leaving the session, leader election, etc. The

final argument is the data object itself, in this case the text to send. The resulting code for

the send method is shown in Figure 18.

this.send(Protocol.ALL, Protocol.DATA MESSAGE, text);

Figure 18 Sample usage of the send () method.









Other versions of the send () method contain provisions for specifying the type

of the data contained in the message, and the destination service for the message. By

default, a message originating from a service is received by the same service on all

clients. By specifying another service name, it is possible to send a message to the other

services. This provides inter-service communication if needed.

Figure 19 contains the final code for sending the messages from a text chat

service:

public void actionPerformed(ActionEvent e) {
if (e.getActionCommand() .equalsIgnoreCase("Send"))
{
String text = textField.getText();
textField.setText ("");
try {
this.send(Protocol.ALL,
Protocol.DATA MESSAGE, text);
}
catch (Exception exception) {
System.err.println(exception);
}
}
}
Figure 19 Complete code for the actionPerformed () method for the text chat
service.



Certain aspects of the design of this method should be noted. First, when the

actionPerformed () method is invoked the first step is to determine which

component generated the Action Event. Although this service has only one component

that generates Action Events, it is easy to define a service with more than one component

generating events of this type. In addition, after acquiring the text from the text field, the

content of the text field is cleared, so that the user can type the next message. This

behavior is provided strictly for convenience. Finally, the send () method can generate

an Exception and that Exception must be handled appropriately or re-thrown.









Another important design issue to note is that when the message is read from the

text field and propagated to all clients, the client sending the message does not process

the message at the time the message is sent. Therefore, the user will not see the result of

his action until that action is actually sent and received by the application from which the

message originated. Depending on the available network and the state of the session, this

might result in a noticeable delay between the action and its result. This behavior is

necessary to ensure that all the clients process the messages in exactly the same order.

Although there is nothing to prevent the developer from designing a service that does not

conform to these practices, it should be avoided at all cost.

The complete code for a simple text chat service is listed in Figure 20.


import service.*;
import client.*;
import message.*;
import java.awt.*;
import java.awt.event.*;

public class MyService extends Service
implements ActionListener {
Button sendButton = null;
TextArea textArea = null;
TextField textField = null;

public MyService(String serviceName) {
super(serviceName);
init();
}

public void init() {
setPanelLayout(new BorderLayout());
textArea = new TextArea();
textArea.setText ("");
textArea.setEditable(false);
panel.add("Center", textArea);












Panel p = new Panel();
textField = new TextField("", 20);
p.add(textField);
sendButton = new Button("Send");
sendButton.addActionListener(this);
p.add(sendButton);
panel.add("South", p);
MenuItem m = null;
m = new Menultem("Print State");
m.addActionListener(this);
addMenuItem(m);
addMenuItemSeparator();


public void processMessage(Object message) {
CoreMessage cm = (CoreMessage)message;
Object payload = cm.getPayload();
Header header = cm.getHeader();
textArea.append(header.getSenderID() + ": +
(String)payload + "\n");
}

public void actionPerformed(ActionEvent e) {
if(e.getActionCommand() .equalsIgnoreCase("Send"))
{
String text = textField.getText();
textField.setText("");
try {
this.send(Protocol.ALL,
Protocol.DATAMESSAGE, text); }
catch (Exception exception) {
System.err.println(exception); }





Figure 20 Complete code for the text chat service.



This tutorial shows the least amount of steps to be taken in order to create a basic

simple service. Developers that wish to create more sophisticated services should consult

the API documentation, to learn about the more advanced features of the Service class.

For example, when the client is initialized or any time state recovery is requested, each









service must be reset to its default state. If the service is implemented only with standard

AWT components this task is simple, and the YCab API takes care of that task.

However, if the service contains custom components, then the

resetServicePanel () method in the Service class must also be provided by the

custom service. In addition, the default implementation assumes that each message

received by the service is of the same type, and that the state of each service can be easily

restored simply by using a contiguous portion of previous messages. If that is not the

case, then the service must provide its own implementation of the updateState ()

method, which is responsible for updating the state of the service. Although this tutorial

will not provide step-by-step instructions on how to create a custom updateState ()

or resetServicePanel () method, the YCab API should be sufficient for that

purpose.














CHAPTER 6
CONCLUSIONS AND FUTURE WORK



The evaluation of the YCab application proved to be quite successful in both the

fixed network environment, and the wireless mobile environment. The fixed network

simulated ideal conditions, in which a permanent, high-bandwidth connection is present

at all times with very little, if any, packet loss. Although under most circumstances

packet loss was not a problem, it did occasionally occur during the state recovery stage

when a significant amount of information was sent in order to bring the new client up to

the state of the session. While occasionally losing individual data packets usually does

not present a problem, losing control packets may cause the system to remain in a certain

mode. For example, if a new client does not receive an "End State Recovery" message, it

may hang in state recovery mode indefinitely or until the new client re-requests state

recovery. While this is not detrimental to the session or the new client, it represents an

inconvenience to the collaborator. The current, temporary fix to the YCab environment

is to send the "End State Recovery" message multiple times. While there is still a chance

that all these messages may be lost, this mechanism reduces that probability. A better

solution to prevent such a situation is to treat it in the same fashion as the "Begin State

Recovery/Election" problem. In those instances a timer is started after requesting state

recovery. If the timer expires without receiving a state recovery message, then a "Begin

Election" message is sent out to all the collaborators. For the "End State Recovery"

problem, a timer could be started after the first "Begin State Recovery" message is









received, and would be killed only if a "End State Recovery" message is received. If the

timer expires naturally, the timer should check to see when the last message was received

to decide if the "End State Recovery" message was indeed lost or never sent. By using a

timer, the YCab system would become more fault-tolerant.

Another situation that caused packet loss to occur was during rapid sending of

messages. Apparently, due to network latency, packet loss was quite severe, so in order

to account for it, a send delay was added to the Communication Manager. This

substantially reduced the number of lost packets. Although the developer configures the

delay time, a better remedy to the situation is to have the client adjust the send delay

automatically, according to the network conditions. This can be implemented by adding

additional functionality to the Session Ping service namely the network latency

calculation. Using the calculation to adjust the send delay, YCab could self-adapt to the

network conditions in order to reduce packet loss without manual configuration.















LIST OF REFERENCES


[1] Ackerman, M.S., "Everything You NEED to Know About Collaboration and
Collaboration Software," In proceedings ofJCSE 97, Boston, MA, USA, 1997.

[2] Alonso, R., Chang, Y.L., Iftode, L. & Mani, V.S., "Managing Video Data in a Mobile
Environment," Matsushita Information Technology Laboratory, 2 Research Way,
Princeton, NJ.

[3] Begole, J., Rosson, M.B., & Shaffer, C.A., "Flexible Collaboration Transparency:
Supporting Worker Independence in Replicated Application-Sharing Systems," ACM
Transactions on Computer-Human Interactions, Vol. 6, No. 2, June 1999, pp95-132.

[4] Burridge, R., "Java Shared Data Toolkit User Guide," Version 1.5, April 1999.

[5] Cheng, L., & Marsic, I., "Wireless Awareness for Multimedia Applications," DARPA
Contract No. N66001-96-C-8510, Department of Electrical and Computer
Engineering, Rutgers University, Piscataway, NJ, USA.

[6] Citrin, W., Hammil, P., Gross, M.D., & WarmackF, A., "Support for Mobile Pen-
Based Applications," In proceedings ofMOBICOM 97, Budapest, Hungary, 1997.

[7] Clio Mobile Computing and Communications Solution, http://www.clio.com/.

[8] Cravotta, N., "Wireless standards vie for your app," EDN, May 13, 1999, pp60-72.

[9] De Silva, D. & Pearson, S., "A Wireless Effort Developing Java Applications for
Embedded Devices," Java Report, April 2000, pp43-58.

[10] Dourish, P., & Bly, S., "Portholes: Supporting Awareness in a Distributed Work
Group," In proceedings of CHI'92, May 1992.

[11] Guerlain, S., Lee, J., Kopischke, T., Romanko, T., Reutiman, P., & Nelson, S.,
"Supporting collaborative field operations with personal information processing
systems," Mobile Networks and Applications 4, 1999, pp37-48.

[12] Hodes, T.D., Katz, R.H., Servan-Schreiber, E., & Rowe, L., "Composable Ad-hoc
Mobile Services for Universal Interaction," In proceedings ofMOBICOM 97,
Budapest, Hungary, 1997.









[13] Housel, B.C. Ph.d, "WebExpress: A System for Optimizing Web Browsing in a
Wireless Environment," In proceedings ofMOBICOM 1996, Rye, NY.

[14] Java TM Shared Data Toolkit Home Page, http://java.sun.com/products/java-
media/j sdt/index.html.

[15] Kaashoek, M.F., Pinckney, T. & Tauber, J.A, "Dynamic Documents: Mobile
Wireless Access to the WWW," In proceedings of the IEEE Workshop on Mobile
Computing Systems and Applications, Santa Cruz, CA, December 1994.

[16] Kirch, O., Linux Network Administrator's Guide, O'Reilly & Associates, 1995,
pp60-62.

[17] Kortuem, G., Bauer, M., & Segall, Z., "NETMAN: The design of a collaborative
wearable computer system," Department of Computer and Information Science,
University of Oregon, Eugene, OR, USA.

[18] Liao, T., "Light-weight Reliable Multicast Protocol," INRIA, Rocquencourt, BP
105, 78153 Le Chesnay Cedex, France.

[19] Ling, J., Helal, A., & Elmagarmid, .A., "Client-Server Computing in Mobile
Environments," to appear in ACM Computing Service, 1999

[20] Lotus Development Corporation, http://www.lotus.com/home.nsf/welcome/notes.

[21] Luff, P., Heath, C., "Mobility in Collaboration," In proceedings of CSCW98,
Seattle, Washington, USA, 1998.

[22] MaaB, H., "Location-Aware Mobile Applications based on Directory Services,"
In proceedings ofMOBICOM 97, Budapest, Hungary, 1997.

[23] Madruga, E. L. & Garcia-Luna-Aceves, J.J., "Scalable Multicasting: The Core-
Assisted Mesh Protocol," Computer Engineering Department, Baskin School of
Engineering, University of California, Santa Cruz, CA.

[24] Mandviwalla, M., & Olfman, L., "What Do Groups Need? A Proposed Set of
Generic Groupware Requiremens," ACM Transactions on Computer-Human
Interaction, Vol. 1, No. 3, September 1994, pp 245-268.

[25] McDonald, A. B. & Znati, T., "A Mobility Based Framework for Adaptive
Clustering in Wireless Ad-Hoc Networks," IEEE Journal on Selected Areas in
Communications, Vol. 17, No. 8, August 1999.

[26] Myers, B.A., Stiel, H., & Gargiulo, R., "Collaboration Using Multiple PDAs
Connected to a PC," In proceedings CSCW98, Seattle, Washington, USA, 1998.









[27] NCSA Habanero, http://havefun.ncsa.uiuc.edu/habanero/.

[28] Neal, L., "Virtual Classrooms and Communities," In proceedings of GROUP 97,
Phoenix, Arizona, USA, 1997.

[29] NetMeeting Home, http://www.microsoft.com/windows/netmeeting/.

[30] Netwave Technologies, Inc., http://www.netwave-wireless.com/.

[31] Nunamaker, J.F, "Collaborative Computing: The Next Millennium," Computer,
September, 1999, pp66-71.

[32] Palm.com, http://www.palm.com/.

[33] Psion PLC, http://www.psion.com/.

[34] Royer, E. & Toh C.K., "A Review of Current Routing Protocols for Ad-Hoc
Mobile Wireless Networks," Department of Electrical & Computer Engineering,
University of California, Santa Barbara.

[35] Satyanarayanan, M., "Fundamental Challenges in Mobile Computing," School of
Computer Science, Carnegie Mellon University, to appear in IEEE Computer.

[36] Seal, K. & Singh, S., "Loss Profiles: A Quality of Service Measure in Mobile
Computing," NFS grant number NCR-9410357, Department of Computer Science,
University of Carolina, Columbia, SC.

[37] Spellman, P.J, Mosier, J.N., Deus, L.M., & Carlson, J.A., "Collaborative Virtual
Workspace," In proceeding of GROUP 97, Phoenix, Arizona, USA, 1997.

[38] Stevens, R. TCP/IP Illustrated, Volume 1: The Protocols, Addison-Wesley
Publishing Company, Massachusetts, 1994.

[39] Symbian, http://www.symbian.com/.

[40] Webopedia, http://webopedia.internet.com/TERM/A/API.html.

[41] Whalen, T., & Black, J.P., "Adaptive Groupware for Wireless Networks," In
proceedings ofMOBICOM 99, New Orleans, LA, 1999.

[42] Windows CE, http://www.microsoft.com/windows/embedded/ce/default.asp.

[43] Windows NetMeeting 3 SDK, http://www.microsoft.com/netmeeting/.




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs