a framework for synchronous and ubiquitous collaboration advisor & chairperson : dr. geoffrey...
Post on 02-Jan-2016
214 Views
Preview:
TRANSCRIPT
A FRAMEWORK FOR SYNCHRONOUS AND
UBIQUITOUS COLLABORATION
Advisor & Chairperson : Dr. Geoffrey FoxCommittee Faculty : Dr. Dennis Gannon, Dr. Kay Connelly, Dr. Sun Kim
Kangseok Kimkakim@cs.indiana.edu
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
3
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
Application Instance
Application Instance
Application Instance
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)
(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)
(loc k ,grantDeny ,newReq)
oldReqs
(loc k ,grantDeny ,newReq)
(loc k ,newReq)
(loc k ,newReq)
if !res pons e = 4then 1` (loc k ,newReq)els e empty
if !res pons e = 3then 1` (loc k ,newReq)els e empty
(loc k ,grantDeny ,newReq)
(loc k ,grantDeny ,newReq)
(loc k ,newReq)
(loc k ,newReq)
if !res pons e = 2then 1` (loc k ,newReq)els e empty
if !res pons e = 1then 1` (loc k ,newReq)els e empty
(loc k ,grantDeny ,newReq)(loc k ,newReq)
if !res pons e = 0then 1` (loc k ,newReq)els e empty
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
L oc kxGrantDenyxNewReq
D
L oc kxGrantDenyxNewReq
Nodes
L oc kxGrantDenyxNewReq
C
L oc kxGrantDenyxNewReq
SimulationStart
1` 1
COUNT
Reques tNodes
COUNT
TimeOver
BOOL
Waiting T ime
1` 0
INT
Time
INT
B
L oc kxGrantDenyxNewReq
StateInformation
Table1` []
OldReqs
A
L oc kxGrantDenyxNewReq
Releas ed
L oc kxNewReq
Exc lus ive
L oc kxNewReq
Shared
L oc kxNewReq
Implic it
L oc kxNewReq
Dec is ionDone
L oc kxGrantDenyxNewReq
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
Mean completion time of a request vs. Mean requestinterarrival time (3000 milliseconds)
0
5000
10000
15000
20000
25000
30000
35000
40000
Desktop Desktop +Cellphone
Cell phone
Mean request interarrival time in milliseconds
Mea
n c
ompl
etio
n t
ime
ofa
requ
est
in m
illis
econ
ds
GridFarmNCSASDSC
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 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
top related