1 / 71

BASS Application Sharing System

BASS Application Sharing System. Omer Boyaci September 10, 2008 www.cs.columbia.edu/~boyaci/appshare. Overview . Introduction Demo Architecture Challenges Features Conclusion. Application Sharing Models. Application specific + Efficient - Participants need application

jenis
Download Presentation

BASS Application Sharing System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 4 2 3

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

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

  12. Screenshot (BASS) 1 4 2

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

  14. Overview Introduction Demo Architecture Challenges Features Conclusion

  15. Demo 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

  23. BASS Windows Server Architecture

  24. BASS Windows Server Architecture

  25. 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. Multimedia Support (Movies) 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:20 1:4 1:5 1:30

  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 ? -1,0,1 coordinates PNG Size counter YES Time Stamp New Region ? Create a record & Start Checking Region record YES NO Detected ? Continue Checking Use Detected Format 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) Movie File (wmv,mpg,divx) FFMpeg2Theora Java Client Theora Movie Java Streaming Server 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. Different Client Bandwidths/Speeds 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

  47. 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

More Related