Collaborative Visualization: A Review and Taxonomy Dr. Ian J. Grimstead Prof. Nick J. Avis Prof. David W. Walker Cardiff School of Computer Science Cardiff, Wales, UK

1
Collaborative VisualizationA Review and
TaxonomyDr. Ian J. GrimsteadProf. Nick J.
Avis Prof. David W. WalkerCardiff School of
Computer ScienceCardiff, Wales, UK
2
Presentation Structure

• Taxonomy selection of grouping
• Selection of attribute for comparison
• Analysis Polar plot
• Closer analysis Scatter plot
• Advances in technology over time
• Conclusion.

3
TaxonomyFive Types of System

• 1. Collaborative problem solving environments
• Component-based workflow, middleware
• 2. Virtual-Reality environments
• Collaborative (CVR) or Multi-User (MVR)
• 3. Multi-player online games
• Wide range of systems, network, etc.
• Paying users trust issues
• 4. Multi-user enabling of single-user app
• Single machine, security issues
• 5. Other systems
• Digital lab books, meeting support, data
  visualization
• More specialist in nature.

4
Five Types of System (cont)

• Why this grouping? Other possibilities
• Real-time interaction systems
• Trusted systems
• Aim
• To note differences between application areas
• Any missed approaches / opportunities?
• Hence grouped by application area
• Rather than by major attribute (e.g. trust).

5
Attribute Comparison Selection of Attributes

• What attributes are there? Examples
• Number of simultaneous users
• Bandwidth requirements
• Are they easy to measure/quantify?
• Bandwidth requirement?
• Need detailed information
• Need attributes we can measure/estimate
• May not be possible to install s/w locally
• e.g. private research s/w
• Must evaluate offline / from published work.

6
Selected Attributes

• 1. Number of simultaneous users
• 1, 10, 100
• 2. User access control
• Global lock, lock per object, no locking
• 3. Communication architecture
• Single server, multiple servers, peer-to-peer
• 4. Type of transmitted data
• Screen, graphical data, raw program data
• 5. User synchronization
• Lock step, loose, asynchronous.

7
Attribute Determination

• Problem
• User access control is often undefined
• Guesstimate added
• Not reliable enough for analysis
• Hence user access control is skipped
• Remaining 4 attributes?
• Sufficient information for guesstimates.

8
Polar Plot forSystem Comparison

• Ratings mapped to range 1-3
• e.g. 10, 100, 1000 users mapped to 1,2,3
• Application groups averaged
• Mapped to 0, 90, 180, 270
• Application areas represented by a quad
• Higher values imply more scalability
• Most scalable largest quad
• Should reveal trends.

9
Polar Plot Average Attributes
Any patterns?
10
Polar Plot Scalability

• PSE, MUE, Other
• Least scalable
• Bottleneck
• Single machine (MUE)
• Central control (PSE)
• MUE skewed
• SameTime (1,000 users)
• Other
• Restricted by design.

11
Polar Plot Scalability (cont)

• Most scalable systems
• Multi-server
• Not peer-to-peer
• Servers under direct administration control
• Preferred to P2P?
• Peer to peer
• Still being tried
• Now a dirty word?
• KaZZa
• Firewall issues
• Off-campus traffic.

12
Improvements Scalability/Resilience

• Scalability
• Systems need to be redesigned to cope
• Convert to peer-to-peer / multi-server
• Difficult to retrospectively engineer
• Integrated audio/video conferencing
• Enable more control over bandwidth
• Resilience
• Multiple peers/servers recording to disk
• Geographically distributed reduce failure.

13
Polar Plot Asynchronous

• Asynchronous
• Increased response time
• Increased users
• Assume more users with async
• Not reflected in plot
• More complex to impl
• Easier traffic reduction techniques.

14
ImprovementsAsynchronous

• Support of asynchronous behaviour
• Reduce requirement on high-speed network
• Few systems are truly asynch
• Mainly data/meeting recording systems
• Enables interaction with recordings
• Reduces need to meet in the same timezone
• CSpray recorded actions replayed
• Can then be amended by others.

15
Attribute Analysis

• User synchronization mainly loose
• Possibly due to incorrect estimates
• Or insufficient published information
• Concentrate on 3 remaining attributes
• Number of users
• Communication architecture
• Access control
• Positions jittered random offset
• Reflect inaccuracies / guesstimate
• Reveals all datapoints.

16
Attribute Analysis Scatter Plot
20 systems presented. Any patterns?
17
Attribute Analysis Scatter Plot

• Per session locking
• Useable with lt10 users
• Easy to implement
• gt100 users
• Per object or none
• Per object locking
• Reduce traffic with world partitioning?
• ?Localised lock/traffic
• Global lock trickier with gt10 users.

18
Advances in TechnologyOver Time

• To investigate changes in technology
• simultaneous users vs. publication date
• Changes from 1996 2004
• Increased network capacity
• Decreased latency
• Increased computer power
• Any effect on published systems?

19
History of Simultaneous Users
Unusual 20,000 users Butterfly.net online game
server support
No discernable trend probably small user base,
so no advantage in supporting 1,000s of users
Over time, new h/w and s/w taken advantage of,
old ideas reused e.g. network locales Community
Place (1997) ? COVEN (1999) ? Butterfly.net
(2003) No major paradigm shift.
20
ImprovementsGrid Technology

• Grid technology is here any use?
• Maturing slowly
• Enables middleware to be created
• Grid toolkits manage system housekeeping
• Useful for multi-server approaches
  (Butterfly.net)
• Still using XML for messaging! (text-based)
• Keep it in mind
• Once standards stabilise
• Or help create them now
• Tuesdays panel
• Distributed simulations and the Grid.

21
ImprovementsPerhaps a Hybrid Approach?

• Peer to peer behind local firewall
• Machines are under moderate control
• Local traffic distributed
• Client-server across firewall
• Trusted peers acts as gateways
• Tightly controlled to support security
• Sys admins can regulate traffic
• Only updates sent to gateway reach external
  network.

22
ImprovementsSystem Interaction

• System interaction
• Many different systems
• can they interoperate?
• No! Well, as far as we can tell
• DIS, HLA expensive to obtain IEEE standards
• Need for open message format?
• Enable legacy applications ? latest apps
• Bigger question perhaps
• Do we wish them to?

23
Conclusion

• Caveat empor
• Imperfect science - very high-level overview
• Useful taxonomy
• Thinking of a new system? Compare with previous
• Scalability of VR,MPOGs gt MUE,PSE
• Must consider scalability at design stage
• Otherwise bottlenecks appear
• No trend to high-end scalability
• Lack of market / requirement / drive?
• Or awaiting a new solution?

24
Questions?

• And, possibly, some answers
• I.J.Grimstead_at_cs.cardiff.ac.uk

25
Appendix

• Or slide graveyard

26
1. Collaborative ProblemSolving Environments
(PSEs)

• Compared to generic problem solving environments
• Such as Mathematica, Iris Explorer
• No inbuilt support for user collaboration
• Collaborative systems
• COVISA, cAVS component-based workflow
• ICENI, CUMULVS middleware.

27
2. Virtual RealityEnvironments

• Two sub-types
• Collaborative VR environments (CVR)
• Multi-user VR environments (MUVR)
• Difference support for user interaction /
  sharing of objects / etc.
• Examples
• CVD, SCAPE fully immersive
• DIVE, COVEN gt100 users.

28
3. Multi-Player Online Games(MPOG)

• Share many facets with VR
• Real-time response
• Multi-user, scalable
• Must cope with a wide range of
• Network bandwidth (modem / ADSL / LAN)
• Systems (bottom range PC / high end gamer)
• Security (trusted servers, untrusted players)
• Various techniques used
• Interpolate past data (Tribes) cpw.
  dead-reckoning
• Distribute object maintenance (Quazals Net-Z).

29
4. Multi-User Enabling of Single-User
Applications (MUE)

• Distributes a single-user program
• On a single machine
• One user can control at any one time
• Can support many viewers (Sametime 1,000)
• Pre-existing applications enabled
• No assumptions can be made
• Hardware graphics supported (VizServer)
• Security issues
• Someones PC is being opened up.

30
5. Other Systems

• Insufficient room in paper for this
• These systems are very varied
• Follow no particular pattern
• Often for an unusual/specific purpose
• Samples sub-grouped as
• Digital lab books (DARWIN, DOE2000)
• Data visualization tools (CSpray, NOVA)
• Meeting support (CoAKTinG, Office o/t Future).

31
Collaborative PSEsDefining Attributes

• Defining attributes
• Users often assume trust
• Scientists cant collaborate without this!
• Not designed for large groups
• lt10 simultaneous users
• Do not require immediate response.

32
Virtual Reality EnvironmentsDefining Attributes

• Immersive environments
• Small number of users
• Specialist platforms
• Non-immersive
• Wide range of number of supported users
• lt10 to gt1000
• Object locking for collaborative VR
• Real-time interaction
• Variety of technologies to load balance
• Peer-to-peer, multi-server, etc.
• Automated re-distribution of load.

33
Multi-Player Online GamesDefining Attributes

• No trust assumed
• Must scale
• Wide range of hardware supported
• Butterfly.net 20,000 users
• Real-time interaction
• Ignoring turn-based games, e.g. chess
• Tools to support this
• High-level instructions sent not low-level moves
  (Age of Empires)
• Interpolate past positions (Half-Life).

34
Multi-User EnablingDefining Attributes

• Security often provided
• Bottlenecks on single host
• Except when this is broadcast read-only
• Often sends using video compression
• Cannot determine applications requirements
• Hence send raw video data.

35
Summary of Analysis

• Caveat empor
• Imperfect science - very high-level overview
• Useful taxonomy
• Searching for a system?
• with N simultaneous users, multi-server?
• No major trend over time
• Scalability
• Asynchronous support rare
• Low-level, detailed data (high volume) often sent
• Cpw. high-level, minimal detail (low volume)
• Multiple servers popular
• Main factor ease of implementation.