Method of Frame Buffer Transmission over Reliable Multicast Network Choon Jin NG Masahiro Takatsuka

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

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.

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

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!

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: Nb <= 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

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)

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.

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.

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.

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

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.

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

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. charbinary 'g'10 'o'11 'p'0100 'h'0101 'e'0110 'r'0111 's'000 ' 001

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.

RMVNC: State transfer Sending RFB message from server to client. New RFB sub-message defined. Allows transfer of compression state to clients. Field TypeDescription Message type4 Padding- Encoder TypeThe encoding used. State lengthThe state data’s length in bytes unit. State dataThe state data.

RMVNC: State transfer Z-lib state transfer message format. Field TypeDescription # of decNumbers of decoder used. Dec mode Zlib decoding mode: METHOD, FLAG, DICT0,1,2,3,4, DONE, BAD. Adler 32The checksum value of the dictionary. [i] Dict length The length of dictionary[i] in unit of bytes followed by its data. Note that [i] = [0.. #dec - 1]. Dict data

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

Result 1: Unicast vs Multicast

Result 1: UltraVNC RMVNC

Result 1: RMVNC

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.

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

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.

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.

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

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.

Result 4: TightProjector

Result 4: RMVNC

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.

Questions & Answers