1. BASS Application Sharing System Omer Boyaci September 10, 2008 www.cs.columbia.edu/~boyaci/appshare

2. Overview Introduction Demo Architecture Challenges Features Conclusion

3. Application Sharing Models Application specific + Efficient - Participants need application - Application has to be modified Generic - Inefficient (sometimes) + Participants don't need application + All applications are supported

4. Application Sharing Models Application specific + Efficient - Participants need application - Application has to be modified Generic - Inefficient (sometimes) + Participants don't need application + All applications are supported

5. Overview Introduction Demo Architecture Challenges Features Conclusion

6. Application Sharing Sharing an application with multiple users There is only one copy of the application Participants do not need application itself Briefly, participants receive screen updates send keyboard and mouse events Desktop sharing is also supported.

7. Screenshot

8. Screenshot (2)

9. Screenshot (Overlapped Windows) 1 2 3 4

10. Screenshot (Multicast App. Tool) 1 2 3 4 4

11. Screenshot (Ultra VNC) 1 2 3 4 4

12. Screenshot (BASS) 1 2 4

13. Supported Platforms/OS *Client is Java based.

14. Overview Introduction Demo Architecture Challenges Features Conclusion

15. Demo

16. Overview Introduction Demo Architecture Challenges Features Conclusion

17. System Architecture Client/Server Software Architecture

18. System Architecture Client/Server Software Architecture Screen Updates

19. System Architecture Client/Server Software Architecture Keyboard Mouse Events

20. Client (Viewer) Architecture Client can –Connect to server –Wait for incoming connections Client supports –TCP –UDP (+Multicast)

21. Client (Viewer) Architecture Client receives these commands –Open new window –Window size changed –Pixel update –Close window Client sends –BFCP (Binary Floor Control Protocol) commands –Keyboard and mouse events

22. BASS Windows Server Architecture

26. Overview Introduction Demo Architecture Challenges Features Conclusion

27. Challenges Different client bandwidths/speeds Late Joiner The effects of packet loss Reliable multicast

28. Multimedia Support (Movies)

29. Our system uses PNG to compress and transmit the region updates PNG is lossless and effective for computer generated images but ineffective for real world captures like pictures or movies JPG is more suitable for photographic images However, JPG is lossy and not effective for computer generated images (text, line, shapes,...) Our system should use both

30. Multimedia Support (Movies) Composite image comparing JPEG and PNG: notice artifacts in JPEG versus solid PNG background.

31. Multimedia Support (PNG vs JPG) Size x 360x150 162K Size 4x 720x300 648K 1:30 1:20 1:51:4

32. Multimedia Support (PNG vs JPG) Ethernet (60Mb/s)

33. Multimedia Support (PNG vs JPG) Wireless (4Mb/s)

34. PNG/JPG Detection Algorithm Region> 40,000px ? YES New Region ? NO Use Detected Format YES -1,0,1 coordinates PNG Size Time Stamp counter Region record Create a record & Start Checking Detected ? Continue Checking NO YES

35. Sharing a Movie (Media Player)

36. Sharing a Movie File Capturing from the Frame Buffer is expensive. Instead –Transcode the movie to Theora beforehand Then stream the theora directly to participants –Java client supports theora playback Negligible CPU usage during playback on the server –

37. Sharing a Movie (Our Method)

38. Sharing a Movie File Movie File (wmv,mpg,divx) Theora Movie FFMpeg2Theora Java Streaming Server Java Client Java Client UDP/Multicast

39. Challenges Different client bandwidths/speeds Late Joiner The effects of packet loss Reliable multicast

40. Different Client Bandwidths/Speeds

41. Possible Solutions –Slowest one –Average speed –Fastest one

42. Different Client Bandwidths/Speeds Possible Solutions –Slowest one Problem: Penalize everybody except the slowest –Average speed –Fastest one

43. Different Client Bandwidths/Speeds Possible Solutions –Slowest one Problem: Penalize everybody except the slowest –Average speed Possible solution –Fastest one

44. Different Client Bandwidths/Speeds Possible Solutions –Slowest one Problem: Penalize everybody except the slowest –Average speed Possible solution (Can we do better?) –Fastest one

45. Different Client Bandwidths/Speeds Possible Solutions –Slowest one Problem: Penalize everybody except the slowest –Average speed Possible solution (Can we do better?) –Fastest one The best solution Client bandwidths are fully utilized

46. Different Client Bandwidths/Speeds

48. Challenges Different client bandwidths/speeds Late Joiner The effects of packet loss Reliable multicast

49. Late Joiner Force server to generate full screen update

50. Late Joiner Force server to generate full screen update –Problems Misbehaving clients can degrade performance If Join/Leave rate is high, too much burden on server –Solution Generate full screen updates if really necessary Otherwise start the new client from last full screen update

51. Different Client Bandwidths/Speeds

59. Challenges Different client bandwidths/speeds Late Joiner The effects of packet loss Reliable multicast

60. The effects of Packet Loss This problem applies to –Multicast –UDP The PNG images can be large –Regular desktop can be ~900KB –~600 Ethernet packets – One packet loss wastes all PNG image

61. The effects of Packet Loss Solution –Small PNG images Around ~1500 bytes Consist of a few scanlines –Disadvantages Increased CPU usage (client&server) Lower compression ratio (%20 lower) –Advantages One packet loss = no update for a few scanlines

62. The effects of Packet Loss

63. Challenges Different client bandwidths/speeds Late Joiner The effects of packet loss Reliable multicast

64. Reliable Multicast RTP Library stores last N rtp packets Clients send NACK for lost packets RTP Library resend the requested packets

65. The effects of Packet Loss

66. Overview Introduction Demo Architecture Challenges Features Conclusion

67. Recording Clients can record the whole/part session Anybody can play these files locally These files can be streamed to receivers via streaming server Streaming server supports multiple receivers –Also late joiners

68. Listening Client Client waits for incoming connections It can display windows from multiple user Can be used for RGB cable replacement

69. Overview Introduction Demo Architecture Challenges Features Conclusion

70. Application sharing allows users to share a single application with multiple participants. Participants don't need the application. It is not specific to a single application. Extra features like recording is added.

71. Thanks Questions?