1 / 31

Method of Frame Buffer Transmission over Reliable Multicast Network

Choon Jin NG Masahiro Takatsuka. Method of Frame Buffer Transmission over Reliable Multicast Network. Overview. Introduction Overall issues with screen sharing Limitation of available prototypes Solution Conclusion. Introduction to Screen Sharing.

ula
Download Presentation

Method of Frame Buffer Transmission over Reliable Multicast Network

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. Choon Jin NG Masahiro Takatsuka Method of Frame Buffer Transmission over Reliable Multicast Network

  2. Overview • Introduction • Overall issues with screen sharing • Limitation of available prototypes • Solution • Conclusion

  3. Introduction to Screen Sharing • Screen sharing is important in many CSCW applications. • AT&T Virtual Network Computing (VNC), Microsoft’s Remote Desktop Protocol (RDP), Apple Remote Desktop (ARD) to perform remote administration. • Also in MSN Messenger, Adobe Connect, Skype, WebEx, Vsee & etc for participants to share contents.

  4. Scaling CSCW Collaboration • With bandwidth increase, collaboration technologies has been increasingly complicated. • Involves more and more participants. • Number of connection increase.

  5. Screen Sharing Modes • 1 to 1 • Typical screen sharing. • 1 to * • Does not scale more than 5-10 participants. • Need to duplicate same packet to all nodes. • * to * • Consume tremendous network resources if packet duplication is required for all nodes. • Latency is important factor in CSCW!

  6. Problems with current approach • To scale, improve performance such as TightVNC. • Most systems are designed for unicast connectivity. • Suitable for sharing with 1 person up till about 10 on a single media. • Attempt to improve with multicast screen sharing. • Benefit of multicast: N•b <= c; N =1 • E.g. TightProjector, Teleteaching’s multicast VNC • Based on unreliable network. • Less efficient: (1) Overheads (2) Less compression (3) Retransmission • Net effect: (1) Lower resolution (2) Lower colour

  7. RMVNC:New proposal • Method of reliable multicast • Server multicast frame buffer to clients. • Client module: Initialization on frame buffer parameters. Clients also send all keyboard/mouse commands. Uses unicast. Should be lightweight. • Global module: Transmit all common data. E.g. Frame buffers to client. Uses multicast. Reliable Multicast VNC (RMVNC)

  8. RMVNC:About VNC Protocol • Its protocol is called Remote Frame Buffer (RFB). • RFB provides protocol flexibility. • E.g. Raw, Rect, RRE, CoRRE, Tight, ZRLE. • Stateful compression. • Each client connection regarded as a single session requiring compression state tracking.

  9. RMVNC:Problem with multicast • Multicast is unreliable and unordered • Multicast broadcast same data to everyone • Stateful compression will not work • Hence, prerequisite: Need reliability and FIFO ordering • Now, all clients need to achieve the same state.

  10. RMVNC:Data transmission • Screen pooling: Push model instead of pull. • Reliable multicast • Allows stateful compression • No individual state tracking required • No need retransmission unless packet loss • Still, since all data are same, need to synchronize state.

  11. RMVNC:Possible Solutions • “Flushing” states? • Reset compression states whenever new client connects. Reduced compression efficiency. • Transfer states to client • Able to keep states and continue data streaming • More consistent compression efficiency

  12. RMVNC:Z-lib compression • PKZip, Zip, gzip, ARG, zlib • All use dictionary compression followed by a variable-length decoder. • For z-lib: LZ77 adaptive dictionary algorithm followed by the Huffman coding. • What is dictionary compression? • What is variable-length decoder? • Is a lossless data compression algorithm.

  13. RMVNC:Z-lib compression the_rain_in_Spain_falls_mainly_in_the_plain the_rain_<3,3>Sp<9,4>…… • What is LZ77 dictionary compression? • Recently transmitted words are stored in a buffer. Known as “sliding window”. • Repeating words are replaced with pointers.

  14. RMVNC:Z-lib compression • What is Huffman coding? • “go go gophers” • Statistics of words collected. • Frequent words are assigned shorter binary code. Infrequent words are assigned longer binary code. • Represented with binary tree.

  15. RMVNC:State transfer • For RFB protocols, we can transfer z-lib compressor states: (1) Sliding window dictionary buffer (2) Huffman tree. • In z-lib, data are transmitted in blocks. Each has its own independent Huffman tree. All blocks refer to the same dictionary. • Hence only dictionary buffer transfer is required.

  16. RMVNC:State transfer • Sending RFB message from server to client. • New RFB sub-message defined. • Allows transfer of compression state to clients.

  17. RMVNC:State transfer • Z-lib state transfer message format.

  18. Experiment 1: Unicastvs Multicast • 60 PCs were used. • Unicast: UltraVNC • Multicast: RMVNC • 10 pictures were sent. Number of pictures successfully received recorded.

  19. Result 1: Unicastvs Multicast

  20. RMVNC Result 1: UltraVNC

  21. Result 1: RMVNC

  22. Experiment 2: Desktop activities Bandwidth • Compared RMVNC with other multicast solution: • TightProjector (TP) • Teleteaching’s Multicast VNC (MVNC) • Same desktop activities are applied on all prototypes. • Using web browser and word processor.

  23. Result 2 : Desktop activities Bandwidth • RMVNC and TP transmitting 24-bits. • MVNC transmitting 8-bits. • RMVNC use Tight encoding. • MVNC uses Hextile encoding.

  24. Experiment 3: Major Static Content Bandwidth • Compared RMVNC with other multicast solution: • TightProjector (TP) • Teleteaching’s Multicast VNC (MVNC) • Test static screen with little dynamic content.

  25. Result 3: Major Static Content Bandwidth • TP and RMVNC transmit frame buffer only when screen changes with compression. • MVNC re-transmit all time at 8-bit! • TP spikes when animation change. Has no compression.

  26. Experiment 4: Video Bandwidth • The same YouTube video was played on all 3 prototypes. • To test intense screen activities.

  27. Result 4: Video Bandwidth • No advantage for all prototypes. • But RMVNC was observed having a much smoother video replay. • Being able to encode more image information using stateful compression.

  28. Result 4: TightProjector

  29. Result 4: RMVNC

  30. Conclusion • This paper introduce one method to transfer frame buffer over reliable multicast network. • Provides insight on other possible solutions: • Redesigning protocol • Compression for single unit block without reliability • For reliable multicast, need to consider other factors such as network waiting buffer.

  31. Questions & Answers

More Related