THINCing Together: Multi-User Collaborative Support with THINC

1
THINCing TogetherMulti-User CollaborativeSuppor
t with THINC

• Dave Coulthart, Sudip Das, and Leo Kim
• Computer Science Department
• Columbia University, New York

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-gtisUp FALSE
• ScreenPriv-gtSWCursor TRUE
• Modify just this and you end up with NULL
  pointers
• DisableDevices() - called before LeaveVT -)
• DisableInputHandlers() - called after LeaveVT -(
• 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!
• Leos one hell of a hacker -)
• Tested the extensibility of the THINC
  architecture
• Collaborative changes added minimal overhead
• Asynchronous THINC is hard -(
• Daves 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!)