Post on 16-Dec-2015
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!)