1 IEEE DS-RT 2005 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

2 IEEE DS-RT 2005 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 IEEE DS-RT 2005 Taxonomy: Five 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 IEEE DS-RT 2005 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 IEEE DS-RT 2005 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 IEEE DS-RT 2005 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 IEEE DS-RT 2005 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 IEEE DS-RT 2005 Polar Plot for System Comparison ● Ratings mapped to range 1-3 ● e.g. 10, 100, 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 IEEE DS-RT 2005 Polar Plot: Average Attributes Any patterns?

10 IEEE DS-RT 2005 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 IEEE DS-RT 2005 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 IEEE DS-RT 2005 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 IEEE DS-RT 2005 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 IEEE DS-RT 2005 Improvements: Asynchronous ● 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 IEEE DS-RT 2005 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 IEEE DS-RT 2005 Attribute Analysis: Scatter Plot 20 systems presented. Any patterns?

17 IEEE DS-RT 2005 Attribute Analysis: Scatter Plot ● Per session locking: ● Useable with <10 users ● Easy to implement ● >100 users ● Per object or none ● Per object locking: ● Reduce traffic with world partitioning? ●  Localised lock/traffic ● Global lock trickier with >10 users.

18 IEEE DS-RT 2005 Advances in Technology Over 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 IEEE DS-RT 2005 History of Simultaneous Users No discernable trend; probably small user base, so no advantage in supporting 1,000’s of users Unusual: 20,000 users Butterfly.net online game server support 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 IEEE DS-RT 2005 Improvements: Grid 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 ● Tuesday’s panel ● Distributed simulations and the Grid.

21 IEEE DS-RT 2005 Improvements: Perhaps 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 IEEE DS-RT 2005 Improvements: System 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 IEEE DS-RT 2005 Conclusion ● Caveat empor: ● Imperfect science - very high-level overview ● Useful taxonomy ● Thinking of a new system? Compare with previous… ● Scalability of VR,MPOGs > 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 IEEE DS-RT 2005 Questions? ● And, possibly, some answers…

25 IEEE DS-RT 2005 Appendix ● Or slide graveyard…

26 IEEE DS-RT Collaborative Problem Solving 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 IEEE DS-RT Virtual Reality Environments ● 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: >100 users.

28 IEEE DS-RT 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 (Quazal’s Net-Z).

29 IEEE DS-RT 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 ● Someone’s PC is being opened up.

30 IEEE DS-RT 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 IEEE DS-RT 2005 Collaborative PSEs: Defining Attributes ● Defining attributes: ● Users often assume trust ● Scientists can’t collaborate without this! ● Not designed for large groups ● <10 simultaneous users ● Do not require immediate response.

32 IEEE DS-RT 2005 Virtual Reality Environments: Defining Attributes ● Immersive environments ● Small number of users ● Specialist platforms ● Non-immersive ● Wide range of number of supported users ● 1000 ● 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 IEEE DS-RT 2005 Multi-Player Online Games: Defining 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 IEEE DS-RT 2005 Multi-User Enabling: Defining Attributes ● Security often provided ● Bottlenecks on single host ● Except when this is broadcast read-only ● Often sends using video compression ● Cannot determine application’s requirements ● Hence send raw video data.

35 IEEE DS-RT 2005 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.