a framework for synchronous and ubiquitous collaboration advisor & chairperson : dr. geoffrey...

A FRAMEWORK FOR SYNCHRONOUS AND

UBIQUITOUS COLLABORATION

Advisor & Chairperson : Dr. Geoffrey FoxCommittee Faculty : Dr. Dennis Gannon, Dr. Kay Connelly, Dr. Sun Kim

Kangseok [email protected]

Computer Science Department, School of Informatics Indiana University, Bloomington

2

Outline Motivation Research Issues Collaboration Framework Control Mechanisms

Session Control Access Control Floor Control

Experimental Results Contribution Future Work

4

Key Terminologies Session

online workgroup of collaborators working with sharing various collaborative applications.

Synchronous collaboration enable different users of a session to share the same resource in real ti

me (at the same time) all participants in collaboration always have the same views and data in

real time Asynchronous collaboration

allow different users of a session to access the same resource at different times

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)

Ubiquitous collaboration capability of multiple users to link together with disparate access device

s in anytime and anywhere

5

Role Definitions Administrator

Define policies and manage conference manager Chairperson

Create or destroy sessions Control sessions and participants’ presence in a

conference by a set of session protocols Moderator or Master

A person who plays a control role in a session e.g. Control who has a floor for a shared

whiteboard Requester

Normal user

6

Research Issues I 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.

Ubiquitous collaboration Current virtual conferencing systems lack support for ubiquit

ous collaboration. Make systems more usable and more useful, and enable pe

ople to work together with roaming users as well as others remotely.

7

Research Issues II 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.

Group coordination (Floor control) As users try to manipulate shared application at the same ti

me, 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

Collaboration Framework Built on heterogeneous (wire, wireless) computing environmen

t. Handle cooperation and communication among heterogeneous

communities. Provide collaborative applications in the heterogeneous commu

nity collaboration. Shared event mechanism. 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

A Framework Architecture

Session/Membership Control Manager Access/Floor Control Manager

Control Manager

JoinConf Handler

Action Request/Reply Handler

Communication Channel

Session

Application Instance

SessionList Handler

UserList Handler

JoinConf XGSP Message

UserList XGSP Message

SessionList XGSP Message

Request/Set Action XGSP-XRBAC Message

Policy Manager




Broad View Architecture

Conference Manager

(Web Server)

Application(Instant Messenger)

Proxy

Application(Whiteboard)

Filter

Message / Service Middleware (Broker)

Registries of all scheduled conferencesUser accountsPolicies

User Node

User roster

Session roster

Application Instance 0

Control manager

Application Instance 1

User Node User Node User Node

11

XGSP (XML based General Session Protocol)

Means control logic defined in XML. manage presence membership maintain connectivity among collaborators organize online sessions support heterogeneous community collaboration

To maintain consistent state information among sessions and collaborators in a coordinated way. We use query-dissemination interaction event messaging me

chanism with publish-subscribe messaging service. provide a flexibility for adapting dynamic changes of colla

boration states (creation and destroy of sessions, and presences of users in sessions)

12

XGSP-Floor (XGSP Floor Control) In a face-to-face offline session, users generally follow rules of etiquette or

social protocol when they interact with each other. In online session, users usually interact with each other using computer-me

diated policies and tools. Floor control policy and mechanisms have to be able to provide a floor on s

hared application for only one user in online session at any time.

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

Examples

Broker

Major event

(Moving object)

Major event

(Moving object)

XGSP event XGSP event

XG

SP e

vent

Drawin

g ev

ent Draw

ing event

Dra

win

g e

vent

Text event Text event

Major event(Moving object)

14

XGSP-Floor Policy Floor policy means how users request applications, how the

applications are assigned and released.

Request Users can request through the use of XGSP-Floor control tool Moderator can directly assign a floor to collaborators

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. 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

XGSP-Floor Mechanism Determination of types classified to access applications

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

Access types: Exclusive, Shared, Released, Implicit

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

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.

Moderator

FloorRequestQueue

2. Access TypeDecision Service

3. Access and Floor Control Decision Service

1. PolicyStore

4. Current Floor StateInformation Table

FloorWaitingQueue

Decision

Access / Floor Control Manager

Floor Requesters

Non-optimistic Locking Mechanism with Shared Whiteboard

Access / FloorControl Manager

BROKER

1. Lock

2. Request Floor3. 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

Moderator

Request-Response Interaction Scheme between a Moderator and a Floor Requester with Human-Computer Interaction

BROKER

Access /Floor

ControlManager

Set Floor

Set Floor

Request FloorRequest Floor

Decision

Decision(Grant, Deny,

Queued, Release)

Moderator

Requester

19

XGSP-RBAC (XGSP Role Based Access Control)

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

XGSP-RBAC Use roles based on users’ privileges and devices’ capabilities Define policies in XML to enable only authorized users to access protect

ed 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)

XGSP-RBAC Architecture

Moderator

Requester

7. DecisionResponse

2. AccessRequest

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

DecisionResponse

AccessRequest

GUIFine-grainedactions

Push modepolicy is passed to a user at conference join time this leads to policy consistency

Pull mode policy is retrieved from internal store at access time

21

Experimental Measurements Formal Verification by Colored Petri Net Baseline Performance Test Query and Dissemination Time of Sessions Transfer time of Image from Desktop to Cell

phone 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

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

22

Formal Verification by Colored Petri Net

We modeled the mechanisms (XGSP-RBAC and XGSP-Floor) and verified the modeled mechanisms in terms of mutual exclusion, dead lock, and starvation.

The key part for the modeling and formal verification is to show consistent shared state at application level to collaborators.

23

Abstract Representation of Control Mechanism by Colored-Petri Net

if boolsthen 1` (IntInf.to Int (time()))e ls e empty

if s haredReqs < > [] then s etF als eAc tion(s haredReqs )els e s haredReqs

oldReqs

if grantDeny = give orels e grantDeny = re leas ed then (s ort OldReq.lt tmpReqs )els e o ldReqs

(loc k ,grantDeny ,newReq) (loc k ,grantDeny ,newReq)

(loc k ,grantDeny ,newReq)

oldReqsif grantDeny = grant then (s ort OldReq.lt tmpReqs )els e o ldReqs

if grantDeny = givethen 1` loc kels e empty

loc k if grantDeny < > releas ed andals o grantDeny < > givethen 1` loc kels e empty

if bools andals o s haredReqs < > []then timeOverAc tion(s haredReqs )els e s haredReqs

s haredReqs

oldReqs

s haredReqs

s haredReqs

if s haredReqs = []then s haredReqsels e rm (hd s haredReqs ) s haredReqsif s haredReqs < > []

then 1` (loc k , grantDeny , hd s haredReqs )els e empty

loc k

if grantDeny = releas edthen 1` loc kels e empty

(loc k ,grantDeny)

(loc k ,grantDeny)

loc k

s haredReqs

s haredReqs

bools

s haredReqs

if ex is tAc tion(newReq, o ldReqs )then (s haredReqs ^ ^ [newReq])els e s haredReqs

(loc k ,grantDeny ,newReq) (loc k ,grantDeny ,newReq) (loc k ,grantDeny ,newReq) (loc k ,grantDeny ,newReq)

if grantDeny = re leas ed orels e grantDeny = givethen 1` (loc k ,grantDeny ,newReq)els e empty

(loc k ,grantDeny ,newReq)(loc k ,grantDeny ,newReq)


n

n@+ expTime(100)

n if n= kthen emptyels e 1` ((n+ 1)@+ expTime(100))

if s haredReqs = [] orels e timeChec kAc tion(hd s haredReqs )then newReqs ^ ^ [newReques t()]e ls e [o ldReques t(hd s haredReqs )]^ ^ newReqs

newReqs

proc time

if GT(proc time, re leas edtime) andals o s haredReqs < > []then trueels e fa ls e

if GT(proc time, re leas edtime)then 1` proc timeels e 1` releas edtime

releas edtime

releas edtime

proc time

IntInf.to Int (time())

loc k

if s haredReqs < > [] andals o o ldReqs < > []then (loc k ,grantDeny ,findAc tion(hd s haredReqs , o ldReqs ))e ls e (loc k ,grantDeny ,newReq)

(loc k ,grantDeny ,newReq)(loc k ,grantDeny ,newReq)


oldReqs


(loc k ,newReq)

(loc k ,newReq)

if !res pons e = 4then 1` (loc k ,newReq)els e empty




(loc k ,newReq)

(loc k ,newReq)



(loc k ,grantDeny ,newReq)(loc k ,newReq)


newReq::newReqs

newReqs(loc k , newReq)@+ proc time

(loc k ,newReq)

UpdateTable

input (newReq, o ldReqs );output (tmpReqs );ac tionc hangedAc tion(newReq, o ldReqs , o ldReqs );

GiveF looroutput (grantDeny);ac tiondec is ionGive();

GIVEorUnloc k

Unloc k

TimeOver

Trans mitReply

Rec eiveDec is ion

Rec eiveReply

input (newReq, o ldReqs );output (tmpReqs );ac tionc hangedAc tion(newReq, o ldReqs , o ldReqs );

SendReply

Init

Arriva l

Polling

Trans mitDec is ion

D4

input (newReq, o ldReqs );output (grantDeny);ac tionif ex is tAc tion(newReq, o ldReqs )then dec is ionQueued()els e dec is ionGrant()

D5

input (s haredReqs );output (grantDeny , re leas edtime);ac tionif s haredReqs = []then dec is ionGR()els e dec is ionGT()

D3

output (grantDeny);ac tiondec is ionGD();

D2

output (grantDeny);ac tiondec is ionGrant();

SendDec is ion

D1

output (grantDeny);ac tiondec is ionDeny();

StopStart

output (proc time);ac tionexpTime(90);

Z

L oc kxGrantDenyxNewReq

L

L oc k

GiveF loor

L oc k

U

L oc kxGrantDeny

WaitingL is t

Queue

1` []

SharedReqs

E


D


Nodes


C


SimulationStart

1` 1

COUNT

Reques tNodes

COUNT

TimeOver

BOOL

Waiting T ime

1` 0

INT

Time

INT

B


StateInformation

Table1` []

OldReqs

A


Releas ed

L oc kxNewReq

Exc lus ive

L oc kxNewReq

Shared

L oc kxNewReq

Implic it

L oc kxNewReq

Dec is ionDone


Invalid

L oc kxNewReq

Reques tQueue

1` []

NewReqs

NextReques t

loc k

L oc k

Bus y

L oc kxNewReq

1 1` []

1 1` 1@01 1` 0

1 1` []

1 1` []

1 1` loc k@0

Simplied Abstract Representation of Control Mechanism

SimulationStart

Init

RequestNodes

Arrival

RequestQueue

PolicyStore

Access TypeDecision Service

Real Code

SendDecision

Nodes

Access and Floor ControlDecision Service

Current Floor StateInformation Table

Critical Section

Waiting List Queue

Unlock

Communication Service

1

2

3

4

5

25

Baseline Performance Results

SDSC

NCSA

CGL at IU

9.37 ms / 1 byte54.65 ms / 60 KB

0.43 ms / 1 byte13.79 ms / 60 KB

64.78 ms / 1 byte353.44 ms / 60 KB

2.58 sec / 1 byte28.43 sec / 60 KB

2.33 sec / 1 byte22.18 sec / 60 KB

2.34 sec / 1 byte22.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.

Baseline Performance Results I

Latency in Round Trip Time(Desktop - Broker - Desktop)

0

100

200

300

400

500

600

10 20 30 40 50 60 70 80 90 100Data size in kilobytes

Tim

e in m

illise

conds

GridFarm NCSA SDSC

Baseline Performance Results II

Latency in Round Trip Time(Cell phone - Broker - Cell phone)

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

1 2 3 4 5 6 7 8 9 10

Data size in kilobytes

Tim

e in

mill

isec

onds

GridFarm NCSA SDSC

Experimental Results IQuery and Dissemination Time of Sessions

Query and Dissemination Time of Sessions(Desktop - Broker - chair node - Broker - Desktop)

0

20

40

60

80

100

120

140

160

180

200

10(1.4)

20(2.7)

30(3.9)

40(5.2)

50(6.5)

60(7.8)

70(9.1)

80(10.3)

90(11.6)

100(12.9)

Session size in number (Data size in kilobytes)

Tim

e in m

illiseconds GridFarm NCSA SDSC

<RequestSessionList><UserID>kakim</UserID><ConferenceID>testroom</ConferenceID></RequestSessionList>

<ReplySessionList><UserID>kakim</UserID><ConferenceID>testroom</ConferenceID><SessionList> Session list in testroom conference</SessionList></ReplySessionList>

Experimental Results II Query and Dissemination Time of Sessions

Query and Dissemination Time of Sessions(Cell phone - Broker - chair node - Broker - Cell phone)

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10(1.4)

20(2.7)

30(3.9)

40(5.2)

50(6.5)

60(7.8)

70(9.1)

80(10.3)

90(11.6)

100(12.9)

Session size in number (Data size in kilobytes)

Tim

e in m

illise

conds

GridFarm NCSA SDSC

30

Application (Whiteboard) Filter Architecture View

Broker

Filter

Display

Display

DisplayTranscoding

Graphical display data(Image or drawingobject data)

Pre-transcodingProblem: as new device or new type of application is added, all types of applications have to be updated

Post-trancodingProblem: wireless network and cell phone does not support the transfer of more than 60 KB

31

Image Filtering Structure

Create Image

Create Buffered Image

Scale Image

Convert to PNG

Broker

Whiteboard Application Filter

1.BinaryImage 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

Experimental Results III Transfer time of Image from Desktop to Cell phone

Transfer time of Image from Desktop to Cell phone

0

5000

10000

15000

20000

25000

GridFarm NCSA SDSCLocations

Tim

e in m

illiseconds

Filtering Time

Image Transfer Time

In our experiments, 1 MB (on desktop) image size is transformed into 52 KB (for cell phone) image size by application filter.

800x600 JPEG Image on Desktop vs. 158x134

PNG Image on Cell Phone

60 KB (JPEG)800 x 600

50 KB (PNG)158 x 134Shrunk size

0.2 x 0.2

Experimental Scenario Overview

BrokerAccess Request Simulator

Moderator Node(Decision Node)

<RequestAction>

Request arrivals with exponential distribution

with mean interarrival time (3 seconds)

<SetAppAction>

Three different network combinations over three different locations:1. 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)

Request Nodes

35

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

DecisionProcedure

Moderator Requesters

Decision Response

AccessRequest

Td Tw Tn = Treq + Tres

Ttotal = Td + Tw + Tn

36

Experimental Results IV Mean completion time of a request vs. Mean request interarrival time (3000 milliseconds)

Mean completion time of a request vs. Mean requestinterarrival time (3000 milliseconds)

0

1000

2000

3000

4000

5000

6000

Desktop Desktop +Cellphone

Cell phone

Mean request interarrival time in milliseconds

Mea

n co

mpl

etio

n tim

e of

are

ques

t in

mill

isec

onds

GridFarmNCSASDSC

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

Experimental Results VReply + Non-Blocking vs. No-Reply + Blocking


0

5000

10000

15000

20000

25000

30000

35000

40000


Cell phone


Mea

n c

ompl

etio

n t

ime

ofa

requ

est

in m

illis

econ

ds

GridFarmNCSASDSC


0

1000

2000

3000

4000

5000

6000


Cell phone


Mea

n co

mpl

etio

n ti

me

ofa

requ

est

in m

illis

econ

ds

GridFarmNCSASDSC

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)

38

Contribution I: System Research A framework for synchronous and ubiquitous

collaboration Designed a framework for controlling sessions, accesses,

and floors for synchronous and ubiquitous collaboration as well as heterogeneous community collaboration

XGSP-RBAC Flexible and fine-grained access control mechanism based

on RBAC model XGSP-Floor

A floor control mechanism with a major event conflict detection strategy and a non-optimistic locking strategy to maintain consistent shared state at application level

Provides flexibility from free-for-all to application specific floor control mechanism

XGSP Extended a general solution for heterogeneous community

collaboration Formal verification of modeled control mechanisms (XGSP-

RBAC and XGSP-Floor) mutual exclusion, deadlock, starvation

39

Contribution II: System Software Building of a framework on both cell phone and

desktop Defined general session protocol in XML (XGSP) This includes another colleague’s contribution on desktop

Design and implementation of XGSP-RBAC and XGSP-Floor

Building of application filter for cooperation of heterogeneous types of whiteboard applications

Building of application proxy for Instant Messenger Building of collaborative applications on cell phone

Text Chat, Instant Messenger, Shared Whiteboard with Image Annotation

Modeling of control mechanisms (XGSP-RBAC and XGSP-Floor)

Use of Colored Petri-net to prove the correctness of the modeled mechanisms

40

Future Work Fault-tolerant role delegation mechanism with role hierarchy pol

icy A recovery approach from failure-prone system

Design issues for building applications on mobile devices An approach to overcome technical limitation occurring as p

orting applications from desktop computers (moderate screen size) to mobile devices (small screen size)

e.g. Collaborative chess game on cell phone Support for floor control of synchronous collaborative media ap

plications such as audio / video Extension to new generation of cell phone such as

iPhone iPhone – multimedia and Internet-enabled mobile phone

a framework for synchronous and ubiquitous collaboration advisor & chairperson : dr. geoffrey...

Documents

access control policies

control role

collaboration systemoperations

collaboration frameworkbuilt

shared resources

shared application

unauthorized access

wider range of collaboration