Method of Frame Buffer Transmission over Reliable

Multicast Network

Choon Jin NGMasahiro 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: 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

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.Unicast Frame Buffer

Server

f(s1)

f(s2)

f(s3)

Compressorstate

Multicast Frame Buffer Server

f(s1)Compressorstate

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_<3,3>Sp<9,4>……

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.

char binary'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.

Padding(1 byte)

Encoder Type(4 byte)

State length(4 byte) State data

Message Type (1 byte) Data payload (undefined byte)

Field Type Description

Message type 4

Padding -

Encoder Type The encoding used.

State length The state data’s length in bytes unit.

State data The state data.

RMVNC:State transfer

• Z-lib state transfer message format.

# of dec (2 byte)

Dec mode(2 byte)

Adler 32 value(8 byte)

Dict(i) length(4 byte) Dictionary(i) data

Field Type Description

# of dec Numbers of decoder used.

Dec mode Zlib decoding mode: METHOD, FLAG, DICT0,1,2,3,4, DONE, BAD.

Adler 32 The 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

0 10 20 30 40 50 60 700

2

4

6

8

10

12

10 Picture Change Test (1 picture/sec)

UltraVNCMVNC

Number of clients

Num

ber

of im

ages

rec

eive

d (o

ut o

f 10

)

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