THINCing Together: Multi-User Collaborative Support with THINC

1. Dave Coulthart, Sudip Das, and Leo Kim Computer Science Department Columbia University, New York THINCing Together:Multi-User CollaborativeSupport with THINC

2. Introduction What is “THINC”? New thin-client protocol, short for “THin-client INternet Computing” Comparable to VNC, Citrix MetaFrame, etc. What is “THINCing Together”? Multiple-user support for THINC, both synchronous and asynchronous

3. Motivation Why THINCing Together? Thin clients and collaborative software share architectural similarities Our solution combines the two We test the extensibility of THINC protocol Minimal overhead over existing implementation Design ethos: THINC is a thin-client system first, collaborative system second

4. Outline Related work Asynchronous multi-user design Synchronous multi-user design Performance results Conclusions and future work

5. Related Work What is collaborative software? Software that helps people collaborate interactively, of course! Instant messaging, video conferencing, GNUtella, CVS, email... Collaboration-oriented thin-client systems Collaborative VNC Citrix MetaFrame Access Suite, GoToMyPC XMX, XTV

6. Related Work (Cont.) Remote display collaboration software Altiris Vision Apple Remote Desktop Microsoft Remote Assistance Microsoft Netmeeting Application-specific collaborative software SubEthaEdit Microsoft PowerPoint Collaborative

7. Related Work (Cont.) Protocols, toolkits, frameworks, ideology Resource Description Framework (RDF) Remote JFC, JavaParty, SOAP/XML Engelbart, D. “Augmenting Human Intellect: A Conceptual Framework.” (1962) “Augmented Social Network” Numerous research papers

8. Asynchronous THINC -THINC vs. X What THINC Wants Multiple concurrent X/THINC servers Easy to follow code path to isolate device management No modifications to X What X Wants One controlling X server at a time Numerous abstracted interfaces to support different hardware

9. Asynchronous THINC -The Ugly World of X Code Cursor easy to use to track the problem xf86VTSwitch() - The bane of AsyncTHINC LeaveVT()xf86CursorLeaveVT() ScreenPriv->isUp = FALSE; ScreenPriv->SWCursor = TRUE; Modify just this and you end up with NULL pointers DisableDevices() - called beforeLeaveVT :-) DisableInputHandlers() - called afterLeaveVT :-( Understanding these two should also solve similar keyboard issues

10. Synchronous THINC Overview Multiple users sharing the same screen session Three modes of collaboration Single-user (not collaborating) Unmanaged (arguably collaborating) Managed (structured collaboration) Again, design must fit in with existing implementation Single cursor only

11. Unmanaged Collaboration Free-for-all, unstructured List of connected clients tracked by server Server broadcasts framebuffer updates to all clients in list Advantage: everyone can control the cursor/keyboard Disadvantage: everyone can control the cursor/keyboard Design problem: how to manage the cursor?

12. Cursor Management Hardware cursor optimization Need to duplicate cursor events on all clients Issues Cannot duplicate cursor events if you're the one sending them What if I don't want someone else controlling my cursor?

13. Cursor Management (Cont.) Two client cursor modes Attached: Hardware cursor is used for session movement Detached: Software cursor is drawn to represent session movement. Hardware cursor is free to do whatever user wants Keyboard command toggles the modes Slight overhead for drawing software cursor (must manually do fills each time cursor is moved)

14. Managed Collaboration One user controls the screen at a time “Token passing” Token passing managed centrally by server Each client has list of users connected to session User who “owns” the token owns the screen Users without token cannot send I/O events. User can pass token to other users If user with token disconnects, server reassigns token to next user in list

15. Managed Collaboration (Cont.) Username is sent by client, IP logged via accept() and sockaddr_in Client can pass token using key command When passing token, client no longer can send events. Server checks to see if recipient client can receive token. If so, then all connected clients receive update. If not, then token returns to original client. Clients can still attach and detach cursor

16. Managed Collaboration (Cont.) Client lists are updated when: New clients connect Client drops connection Client passes token Clients can still attach and detach cursor Token passing is not quite atomic Authentication issues

17. Testing Plan Compare multi-user vs. original THINC Compare hardware vs. software cursor See how well THINC scales with the number of connected clients Compare THINC to Collaborative VNC

18. Testing Plan Compare multi-user vs. original THINC Compare hardware vs. software cursor See how well THINC scales with the number of connected clients Compare THINC to Collaborative VNC

19. Performance Results -Hard vs. Soft Cursor CPU Utilization Hardware Cursor CPU Cycles: 1,364 (std dev. - 509; 37%) CPU Time: 1.4 ms Software Cursor CPU Cycles: 13,445 (std dev. - 4,416; 33%) CPU Time: 13.5 ms Factor of ten, but still miniscule

20. Performance Results -Server Scalability

21. Conclusions Synchronous THINC is cool! Leo’s one hell of a hacker :-) Tested the extensibility of the THINC architecture Collaborative changes added minimal overhead Asynchronous THINC is hard :-( Dave’s still working on his GDB/code foo Have you seen crazier numbers?!? ;-) Test with SSL disabled Conclusively determine if bandwidth or CPU limited Multiple servers (keep your fingers crossed!)