THINCing Together:Multi-User CollaborativeSupport with THINC

Dave Coulthart, Sudip Das, and Leo Kim

Computer Science Department

Columbia University, New York

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

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

Outline

Related workAsynchronous multi-user designSynchronous multi-user designPerformance resultsConclusions and future work

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

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

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

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

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 before LeaveVT :-) DisableInputHandlers() - called after LeaveVT :-(

Understanding these two should also solve similar keyboard issues

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

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?

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?

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)

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

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

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

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

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

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

Performance Results -Server Scalability

0

500000

1000000

1500000

2000000

2500000

0 5 10 15

Number of Clients

Bytes Sent by Server (bytes/ sec)

0

10

20

30

40

50

60

70

0 5 10 15

Number of Clients

Average Server CPU Utilization

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!)