1. 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. 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. 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. 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. 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. 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. 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. 8 IEEE DS-RT 2005 Polar Plot for System 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. 9 IEEE DS-RT 2005 Polar Plot: Average Attributes Any patterns?

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

17. 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. 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. 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. 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. 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. 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. 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. 24 IEEE DS-RT 2005 Questions? ● And, possibly, some answers… I.J.Grimstead@cs.cardiff.ac.uk

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

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

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

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