A FRAMEWORK FOR SYNCHRONOUS AND UBIQUITOUS COLLABORATION

(1)

A FRAMEWORK FOR

SYNCHRONOUS AND

UBIQUITOUS COLLABORATION

Advisor & Chairperson : Dr. Geoffrey Fox

Committee Faculty : Dr. Dennis Gannon, Dr. Kay Connelly, Dr. Sun Kim

Kangseok Kim

[email protected]

(2)

v

Outline

n

Motivation

n

Research Issues

n

Collaboration Framework

n

Control Mechanisms

Ø

Session Control

Ø

Access Control

Ø

Floor Control

n

Experimental Results

n

Contribution

n

Future Work

(3)

(4)

v

Key Terminologies

n

Session

Ø

online workgroup of collaborators working with sharing various

collaborative applications.

n

Synchronous collaboration

Ø

enable different users of a session to share the same resource

in real time (at the same time)

Ø

all participants in collaboration always have the same views

and data in real time

n

Asynchronous collaboration

Ø

allow different users of a session to access the same resource

at different times

n

Floor control

Ø

mechanism by which interaction with synchronous shared

application is mediated.

Ø e.g. collaborative chess game (only one player can play at a time)

n

Ubiquitous collaboration

Ø

capability of multiple users to link together with disparate

access devices in anytime and anywhere

(5)

v

Role Definitions

n

Administrator

Ø

Define policies and manage conference manager

n

Chairperson

Ø

Create or destroy sessions

Ø

Control sessions and participants’ presence in a

conference by a set of session protocols

n

Moderator or Master

Ø

A person who plays a control role in a session

Ø

e.g. Control who has a floor for a shared

whiteboard

n

Requester

Ø

Normal user

(6)

v

Research Issues I

n

Heterogeneous community collaboration

Ø

Most heterogeneous community collaboration

systems cannot communicate with each other.

Ø

e.g. H.323 <-> AG (Access Grid)

Ø

We need wider range of collaboration by building

integrated collaboration system, which combines

heterogeneous community collaboration into a

single easy-to-use environment.

n

Ubiquitous collaboration

Ø

Current virtual conferencing systems lack support

for ubiquitous collaboration.

Ø

Make systems more usable and more useful, and

enable people to work together with roaming users

as well as others remotely.

(7)

v

Research Issues II

n

Access control in collaboration system

Ø

Operations on shared resources by collaborators

may produce new results on the shared resources.

Ø

Access control policies and mechanisms are needed

to restrict unauthorized access to a variety of

protected resources.

n

Group coordination (Floor control)

Ø

As users try to manipulate shared application at the

same time, a user may have to contend with other

users for access to the shared application.

Ø

To maintain consistent shared state at application

level, we need to control competing accesses.

(8)

v

Collaboration Framework

n

Built on heterogeneous (wire, wireless) computing

environment.

n

Handle cooperation and communication among

heterogeneous communities.

n

Provide collaborative applications in the

heterogeneous community collaboration.

n

Shared event mechanism.

n

Structured as three layers and six major components

Ø

control manager

Ø

session / membership control manager

Ø

access / floor control manager

Ø

policy manager

Ø

request and reply event message handlers

Ø

communication channel

(9)

v

A Framework Architecture

Session/Membership Control Manager Access/Floor Control Manager Control

Manager

JoinConf

Handler Action Request/ReplyHandler

(10)

v

Broad View Architecture

Conference Manager (Web Server) Application (Instant Messenger) Proxy Application (Whiteboard) Filter

Message / Service Middleware (Broker)

ØRegistries of

all scheduled conferences

ØUser accounts ØPolicies User Node User roster Session roster Application Instance 0 Control manager Application Instance 1

(11)

v

XGSP (XML based General Session Protocol)

n

Means control logic defined in XML.

Ø

manage presence membership

Ø

maintain connectivity among collaborators

Ø

organize online sessions

Ø

support heterogeneous community collaboration

n

To maintain consistent state information

among sessions and collaborators in a

coordinated way.

Ø

We use query-dissemination interaction event

messaging mechanism with publish-subscribe

messaging service.

Ø

provide a flexibility for adapting dynamic changes

of collaboration states (creation and destroy of

sessions, and presences of users in sessions)

(12)

v

XGSP-Floor (XGSP Floor Control)

n

In a

face-to-face offline session

, users generally follow rules of

etiquette or social protocol when they interact with each other.

n

In

online session

, users usually interact with each other using

computer-mediated policies and tools.

n

Floor control policy and mechanisms have to be able to provide a

floor on shared application for only one user in online session at

any time.

n

XGSP-Floor

provides flexibility ranging from free-for-all to

application specific floor control mechanism.

Ø Free-for-all (no floor control)

Ø e.g. Text-chat application

Ø Moderator-mediated floor control mechanism

Ø e.g. Shared whiteboard application

Ø Major event conflict detection function (strict conflict avoidance) Ø Non-optimistic locking mechanism

Ø Two-player turn-taking mechanism

Ø e.g. Collaborative chess game application

(13)

v

Examples

Broker

Major

event

(Movin

g obje ct) Majo

r eve_nt (Mov_ing

obje ct)

XGSP e

vent XGS

P eve_nt

XGS P ev en t Drawin g eve

nt Dr awin g e ven_t Dr awin g ev en t

Text event Text event

(14)

v

XGSP-Floor Policy

n

Floor policy means how users request applications, how the

applications are assigned and released.

n

Request

Ø

Users can request through the use of XGSP-Floor control tool

Ø

Moderator can directly assign a floor to collaborators

n

Response

Ø

If the floor is available, a moderator assigns the floor to the

floor requester.

Ø

Otherwise, the floor request is queued into a floor waiting

queue or can be denied.

n

Release

Ø

Floor is assigned to a requester waiting in a floor waiting

queue in FIFO order

Ø

Floor can also be released from directly moderator or after a

prefixed amount of time.

(15)

v

XGSP-Floor Mechanism

n Determination of types classified to access applications

Ø <Action>

<Capabilities>line drawing</Capabilities> <AccessType>shared</AccessType>

</Action>

Ø Access types: Exclusive, Shared, Released, Implicit

n Determination of whether an action in a request exists in current

floor state information table, in other words, a request action conflicts with the action of current floor holder

Ø If the access type is “Exclusive” and request action exists in the floor

state information table, then the request is queued. Otherwise, the request is granted

Ø If the access type is “Released” and a floor waiting queue is not

empty, then the request is granted and the first request in the waiting queue is granted.

Ø If the access type is “Released” and a floor waiting queue is empty,

then the request is granted

(16)

v

Decision Procedures of XGSP-Floor

Mechanism (Strict Conflict Avoidance)

Ø Major event conflict detect function is used to avoid floor conflicts.

Ø This guarantees the mitigation of race conditions of floor requests to a

shared application. Moderato r Floor Req uest Que ue

2. Access Type Decision

Service

3. Access and Floor Control Decision

Service

1. Policy Store

4. Current Floor State Information Table Floor Wait ing Que ue Deci sion Access / Floor Control

Manager

(17)

vNon-optimistic Locking Mechanism with Shared Whiteboard

Access / Floor Control Manager

B R O K E R

1. Lock 2. Request Floor

3. Request Floor

4. Decision

5. Set Floor

(Grant) 6. Grant (unlock)

Ø Fine-grained actions are used to allow more concurrent activity among

participants.

Ø Coarse-grained action can be used to allow a participant to make more

activities at a time.

Ø This mechanism guarantees that the consistent state at application level is

maintained among participants.

Requester

(18)

v

Request-Response Interaction Scheme between a Moderator

and a Floor Requester with Human-Computer Interaction

B R O K E R Access

/ Floor Control

Manag er

Set Floor

Request Floor Request

Floor Decision

Decision (Grant, Deny, Queued, Release)

Moderator

(19)

v

XGSP-RBAC (XGSP Role Based Access Control)

n

RBAC is a scheme that describes access

rights based on roles in an organization.

Ø

Pros: ease of administration, scalable, wide use in Grid and

Distributed system

Ø e.g.

PERMIS (Privilege and Role Management Infrastructure

Standards)

Ø

Cons: not flexible, not effective for fine-grained access control

n

XGSP-RBAC

Ø

Use

roles

based on users’ privileges and devices’ capabilities

Ø

Define

policies in XML

to enable only authorized users to

access protected collaborative applications

Ø

Authorization is performed by explicitly

moderator-mediated

interaction (request-response) mechanism

Ø

Flexibility

– adapting to the state change of collaborative

applications at run time

Ø

Fine-grained action

- defined as the smallest major events

(semantic events)

(20)

v

XGSP-RBAC Architecture

Moderator Requester 7. Decision Response 2. Access Request Conference Manager Message / Service System (Broker)

1. Push Policy

KMC (Key Management Center)

6. Activation / Deactivation Service 5. Access Decision Service 3. Authentication Service

Local Policy Store

4. Pull Policies

Decision Response Access Request GUI Fine-grained actions Push mode

Øpolicy is passed to a user at conference join time

Øthis leads to policy consistency

Pull mode

Øpolicy is retrieved from internal

(21)

v

Experimental Measurements

n

Formal Verification by Colored Petri Net

n

Baseline Performance Test

n

Query and Dissemination Time of Sessions

n

Transfer time of Image from Desktop to Cell

phone

n

Mean completion time of a request vs. Mean

request interarrival time (3 seconds)

Ø

Completion time of a request

= Waiting time + Decision time + Network

transit time

n

Reply + Non-Blocking vs. No-Reply + Blocking

(22)

v

Formal Verification by Colored Petri Net

n

We

modeled

the mechanisms

(XGSP-RBAC and XGSP-Floor) and

verified the

modeled mechanisms

in terms of mutual

exclusion, dead lock, and starvation.

n

The key part for the modeling and formal

verification is

to show consistent shared

state at application level to

collaborators

.

(23)

vAbstract Representation of Control Mechanism by Colored-Petri Net

(24)

v

Simplied Abstract Representation o

Control Mechanism

Simula tion Start Init Requ est Node s Arriva l Requ est Queu e Policy Store Access Type Decision Service Real Code Send Decisio n Nod es Access and Floor

(25)

v

Baseline Performance Results

SDS

C

NCSA

CGL at IU

9.37 ms / 1 byte 54.65 ms / 60 KB

0.43 ms / 1 byte 13.79 ms / 60 KB

64.78 ms / 1 byte 353.44 ms / 60 KB

2.58 sec / 1 byte 28.43 sec / 60 KB

2.33 sec / 1 byte 22.18 sec / 60 KB

2.34 sec / 1 byte 22.86 sec / 60 KB

The latency of wired network is in the range of milliseconds. The latency of wireless network is in the range of seconds.

(26)

(27)

(28)

v

Experimental Results

Query and Dissemination Time of Sessions

<RequestSessionList>

<UserID>kakim</UserID>

<ConferenceID>testroom</ConferenceID>

</RequestSessionList>

<ReplySessionList>

<UserID>kakim</UserID>

<ConferenceID>testroom</ConferenceID> <SessionList>

Session list in testroom conference </SessionList>

(29)

v

Experimental Results I

(30)

v

Application (Whiteboard) Filter Architecture View

Broker

Filt er

Display

Display Transcoding

Graphical display data (Image or drawing object data)

Pre-transcoding

ØProblem: as new device or new type of

application is added, all types of applications have to be updated

Post-trancoding

ØProblem: wireless network and

cell phone does not support

(31)

v

Image Filtering Structure

Create Image

Create Buffered Image

Scale Image

Convert to PNG Broker

Whiteboard Application Filter

1.Binary Image Data

4.Transcoded Binary Image Data

Canvas Size (1024 x 768)

Canvas Size (160 x 144)

2.Binary Image Data 3.Transcoded Binary Image Data

(32)

v

Experimental Results III

Transfer time of Image from Desktop to Cell phone

Ø In our experiments, 1 MB (on desktop) image size is transformed

into 52 KB (for cell phone) image size by application filter.

(33)

v

800x600 JPEG Image on Desktop vs.

158x134 PNG Image on Cell Phone

60 KB (JPEG)

(34)

v

Experimental Scenario Overview

Broker Access Request

Simulator

Moderator Node (Decision

Node)

Request arrivals

with exponential distribution

with mean interarrival time (3 seconds)

Three different network combinations over three different locations: •collaboration using only desktop devices (wired network)

(# of requests = 100)

2. collaboration using only cell phone devices (wireless network) (# of requests = 100)

3. collaboration using desktop and cell phone together (wired + wireless)

(# of requests from desktop =50)+(# of requests from cell phone =50)

(35)

v

Overhead Timing Considerations

Total latency (Ttotal) (Completion time of a request)

= Waiting time (Tw) +

Decision time (Td) +

Network transit time (Tn = Treq + Tres)

Broker Queue

Decision Procedure

Moderator Requesters

Decision Response

Access Request Td Tw Tn = Treq + Tres

Ttotal = Td + Tw + Tn

(36)

vExperimental Results IV

Mean completion time of a request vs. Mean request

interarrival time (3000 milliseconds)

ØWe need to observe user’s behavior with applications considering

responsiveness vs. concurrency and

responsiveness vs. simplicity.

ØWe may need to make the

granularity of fine-grained actions larger to reduce the wireless network overhead.

but it may decrease the amount of concurrency and

introduce complexity.

(37)

v

Experimental Results V

Reply + Non-Blocking vs. No-Reply + Blocking

Reply + Non-Blocking No-Reply + Blocking

Gain of performance from (No-Reply + Blocking) scheme:

ØDesktop: 9.77% (GridFarm), 1.12% (NCSA), 7.51% (SDSC)

ØDesktop + Cell phone: 51.46% (GridFarm), 59.79% (NCSA), 59.83%(SDSC) ØCell phone: 84.88% (GridFarm), 87.42% (NCSA), 86.96% (SDSC)