Rfb

RFB PROTOCOL

B.Tech Seminar report

by

Saurabh Santhosh
ETAHECS043

Department of Computer Science And Engineering
Government Engineering College, Thrissur
December 2010

Seminar Report 2010

Acknowledgment

First of all, I thank the Almighty God for helping me complete this Seminar. I would
also like to express my sincere gratitude to Head of the Department of Computer
Science and Engineering Prof. Manoj Kumar, Assistant Prof. K S Valsaraj, Lec-
turers Mr. Ajay James and Mrs. Baby Syla for providing all the help,motivation
and encouragement from beginning till the end.I am Also hugely indebted to my
friends and other teachers for all their help and support.

Saurabh Santhosh
December 2010
Govt. Engineering College, Thrissur

Dept. of CSE, GEC, Thrissur i

Seminar Report 2010

Contents

1 Introduction 1
1.1 Basic Parts Of RFB Protocol . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Features of RFB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Organization Of the Report . . . . . . . . . . . . . . . . . . . . . . . . 2

2 REPRESENTATION OF PIXEL DATA 3
2.1 Protocol extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 PROTOCOL MESSAGES 5

4 HANDSHAKING MESSAGES 6
4.1 ProtocolVersion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Security Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Security Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5 INITIALISATION MESSAGES 9
5.1 ClientInit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2 ServerInit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6 CLIENT TO SERVER MESSAGES 11
6.1 SetPixelFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2 SetEncodings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3 FramebuﬀerUpdateRequest . . . . . . . . . . . . . . . . . . . . . . . . 12
6.4 KeyEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.5 Keysym . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.6 PointerEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

7 SERVER TO CLIENT MESSAGES 14
7.1 FramebuﬀerUpdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2 SetColourMapEntries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Dept. of CSE, GEC, Thrissur ii

CONTENTS Seminar Report 2010

7.3 Bell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.4 ServerCutText . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

8 ENCODINGS 17
8.1 Raw encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2 CopyRect encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.3 RRE encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

9 IMPLEMENTATION 19

10 CONCLUSION 21

References 22

Dept. of CSE, GEC, Thrissur iii

Seminar Report 2010

List of Figures

1.1 Working of VNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Dept. of CSE, GEC, Thrissur iv

Abstract

Remote Desktop Softwares are those softwares which provide Remote Access. Remote
Access means the ability of a user to log onto a remote computer or network from a
distant location. This usually comprises of computers, a Network, and some remote
access software to connect to the network. Since this involves clients and servers con-
nected across a network,a protocol is essential for eﬃcient communication between
them. RFB protocol is one of such protocols which is used by the client and servers
for communicating with each other and thereby making Remote Access possible.

The purpose of this Paper is to give a general idea as to how this Protocol actually
works. This paper also gives a broad idea about the various messages of this protocol
and how these messages are send and interpreted by the client and server modules.
This Paper also includes a Simple implementation of the Protocol which shows the
various messages and methods and how this protocol is practically used for gaining
remote access.

Seminar Report 2010

Chapter 1

Introduction

RFB (remote framebuffer) is a simple and efficient protocol which provide remote
access to graphical user interfaces.As its Name Suggests it works at the framebuffer
level and thus it is applicable to all windowing systems and applications. Eg. X11,
Windows and Macintosh. It should also be noted that there are other Protocols avail-
able and RFB is the protocol which is used in Virtual Network Computing (VNC)
and its various forms. Due to increase in number of Software products and Services
such protocols play a very important role nowadays.

Figure 1.1: Working of VNC

1.1 Basic Parts Of RFB Protocol
Display Protocol - the display part of the protocol is based on a simple idea. It is
actually based around a single graphics primitive: put a rectangle of pixel data at a
given x,y position.

Dept. of CSE, GEC, Thrissur 1

section 1.3 Seminar Report 2010

Input Protocol - based on a normal workstation model of a keyboard and multi-
button pointing device. Every keypress and mouse events and transferred and simu-
lated at the remote site.

1.2 Features of RFB
RFB protocol speciﬁes the rules for communication between 2 entities RFB client
and RFB server. In Current versions it supports multiple Clients also.RFB is truly a
thin client protocol. The emphasis in the design of this protocol is to make a client
with very less requirements. Thus,Clients can run on widest range of hardware, and
the task of implementing a client is made very simple RFB protocol makes the client
stateless.

RFB protocol gained signiﬁcance after it was used in VNC (Virtual Network Com-
puting) and is very popular protocol nowadays RFB protocol is Open unlike many
other Remote Access Protocols.

1.3 Organization Of the Report
1. Chapter 2 describes the Representation of Pixel Data and Protocol Extensions

2. Chapter 3 Introduces the Various Protocol Messages

3. Chapter 4 describes the Handshaking Messages and Security Types

4. Chapter 5 describes Initialisation Messages

5. Chapter 6 describes Client to Server Messages

6. Chapter 7 describes Server to Client Messages

7. Chapter 8 describes Various Encodings

8. Chapter 9 shows Protocol Implementation

9. Chapter 10 is the conclusion


Seminar Report 2010

Chapter 2

REPRESENTATION OF PIXEL
DATA

The Interaction between server and client begins with a negotiation of the format and
encoding which will be used to send the pixel data. This step is included to make the
job of client easy. The server must always be able to supply the pixel data in the form
the client needs. In case the client can handle different formats,client can choose any
one it wishes. That is why this protocol is called a thin-Client Protocol.

Pixel Format refers to the representation of various individual colors by pixel val-
ues. The most common formats are 24-bit or 16-bit where bit-fields translate directly
to the primary colors , and 8-bit color map where a mapping can be used to obtain
RGB intensities.

Encoding refers to how a rectangle of the above said pixel data will be sent across
the channel. Every triangle of this pixel data is prefixed by a header which contains
the X,Y position of the rectangle on the screen,the width and height of this trian-
gle,and an encoding type which specifies how the pixel data is encoded. In practice
we normally use only the ZRLE, Hextile and CopyRect encodings since they provide
the best compression as far as typical desktops are concerned.



2.1 Protocol extensions
Following are ways in which the protocol can be extended:

New encodings : A new encoding type can be added easily whilst maintaining
compatibility with existing clients and servers. Existing servers will simply ignore
requests encoding which they dont support.

Pseudo encodings : In addition, a client can request a pseudoencoding to declare
to the server that it supports a certain extension to the existing protocol. A server
which does not support the extension will simply ignore the new pseudo-encoding.

New security types :Adding a new security type gives additionalflexibility in
modifyingthe behaviour of the protocol without sacrificing compatibility with exist-
ing clients and servers. A client and server which agree on a new security type can
effectively communicate based on other protocols.


Seminar Report 2010

Chapter 3

PROTOCOL MESSAGES

The RFB protocol can operate over any reliable transport channel, it can be either
byte-stream or messagebased. Usually it is used over a TCP/IP connection.

The protocol actually proceeds through three stages :

First is the handshaking phase in which the client and server agree upon the pro-
tocol version and the type of security to be used for communication.

The second stage is an initialization phase in which the client and server exchange
ClientInit and ServerInit messages. These messages will be discussed in detail later.

The final stage is the normal protocol interaction in which the server and client
exchange various other messages. The client can send any valid messages it wants,
and receive messages from the server as a result.

All these messages should begin with a message-type byte, followed by any message-
specific data. The various descriptions of protocol messages specified here use the
basic types U8, U16, U32,S8, S16, S32 which represent respectively 8, 16 and 32-bit
unsigned integers and8, 16 and 32-bit signed integers. All multiple byte integers spec-
ified (other than pixel values themselves) are in big endian order (most significant
byte first).

The type PIXEL is a derived type which mean a pixel value of bytesPerPixel
bytes, where 8 bytesPerPixel is the number of bits-per-pixel as agreed by the client
and server either using ServerInit message or a SetPixelFormat.


Seminar Report 2010

Chapter 4

HANDSHAKING MESSAGES

4.1 ProtocolVersion
This phase begins by the server sending the client a ProtocolVersion message. This
informs client know which is the highest RFB protocol version number supported by
the server. The client then replies with another message giving the version number
of the protocol which should actually be used. A client can never request a protocol
version higher than that oﬀered by the server. Thus both clients and servers indirectly
provide some level of backwards compatibility by this mechanism.

The ProtocolVersion message consists of 12 bytes interpreted as a string of ASCII
characters in the following format.

”RFB xxx.yyyn” where xxx and yyy are the major and minor version numbers,
usually padded with zeros.

4.2 Security
Next, the server and client must agree on the type of security to be used on the
connection. For this the server lists the security types which it supports by sending
the following message.



After the Client Receive this message,it checks the contents. If the server listed at
least one valid security type client sends back a single byte.

If number-of-security-types is zero, then it can be considered that for some reason
the connection failed (e.g. the server cannot support the desired protocol version).
This is followed by a string describing the reason.

4.3 Security Types
VNC Authentication - when VNC authentication is to be used ,protocol data is to be
sent unencrypted While using this Authentication, Following Steps are used

The server sends a random 16-byte challenge:

The client encrypts the challenge with DES, using a password as key and sends
the 16-Byte response



After this, The protocol continues with the SecurityResult message.

4.4 Security Result
By the end of this phase ,the server sends a word to inform the client whether the
security handshaking was successful.


Seminar Report 2010

Chapter 5

INITIALISATION MESSAGES

After the handshaking pahse , the protocol passes to the initialisation phase.
This phase proceeds as follows:
The client sends a ClientInit message followed by the server sending a ServerInit
message.

5.1 ClientInit

Shared-flag field in the message is non-zero (true) if the server should try to share
the desktop by leaving other clients connected, zero (false) if it should give exclusive
access to the communicating client by disconnecting all other clients.

5.2 ServerInit
As described above, after receiving the ClientInit message, the server sends a ServerInit
message. This message is used to inform the client about the width and height of the
servers framebuffer, its pixel format and the name.



PIXEL FORMAT

Server-pixel-format specifies the servers natural pixel format Bits-per-pixel is the
number of bits used for each pixel. This value should be greater than depth

If true-colour-flag is set (true) then the last six items specify how to extract vari-
ous intensities from the pixel value.

If true-colour-flag is not set (false) the six items serve as indices into a colour map
set using SetColourMapEntries.


Seminar Report 2010

Chapter 6

CLIENT TO SERVER
MESSAGES

The various client to server message types defined in this paper are

For Additional Messages client must first determine that the server supports the
relevant extension by receiving some confirmation from the server

6.1 SetPixelFormat

This Message is used to set the format in which pixel values should be sent in
FramebufferUpdate messages. In Absence of SetPixelFormat message then the server
sends pixel values in its natural format as specified in the ServerInit message as
described earlier. Immediately after the client has sent this message the colour map
is made empty because it is no longer necessary.



6.2 SetEncodings

This Message is used to set the encoding types in which pixel data can be sent
by the server.(also include pseudo-encodings). The server may or may not choose the
encodings suggested by the clients.This supports backward compatibility.

6.3 FramebufferUpdateRequest
This is the Most Important Message sent by the client to the server. The GUI is
transferred as a result of this request message.

This request message notifies the server that the client is interested in the area of
the framebuffer specified by x-position, y-position, width and height.

The server usually responds to a FramebufferUpdateRequest by sending a Frame-
bufferUpdate which will be described later.

A single FramebufferUpdate may be sent in reply to several FramebufferUpdateRequests.
This is responsible for the increased efficiency of RFB protocol.

Only if client has lost the contents of a particular area which it needs, then the
client sends FramebufferUpdateRequest with incremental set to zero.



6.4 KeyEvent

A simple key press or release. Down-flag is non-zero (true) if the key is now
pressed, zero (false) if it is now released. The key itself is specified using the keysym
values defined by the X Window System which is used for simulation.

6.5 Keysym

For most ordinary keys, the keysym is the same as the corresponding ASCII value.
The interpretation of keysyms is a complex area due to the following reasons and
should be implemented with care :
The shift state should be taken into account. State of modifier keys such as Control
and Alt should be taken as modifying the interpretation of other keysyms.

6.6 PointerEvent

Indicates either pointer movement or a pointer button press or release which is
essential for its Simulation. The pointer is now at (x-position, y-position), and the cur-
rent state of buttons 1 to 8 are represented by bits 0 to 7 of button-mask respectively,
0 meaning up, 1 meaning down (pressed).


Seminar Report 2010

Chapter 7

SERVER TO CLIENT
MESSAGES

The various server to client message types defined are

Before sending new messages a server must have determined that the client sup-
ports the relevant extension by receiving some confirmation from the client - usually
a request.This is done with the help of message specified earlier.

7.1 FramebufferUpdate
The contents of this message is used to reproduce the GUI at the client computer. A
framebuffer update consists of a sequence of rectangles of pixel data which the client
should put into its framebuffer.



Followed By

7.2 SetColourMapEntries
This message is used only when the color map is used ; this message tells the client
that the speciﬁed pixel values should be mapped to the given RGB intensities as de-
scribed earlier.

Followed By

7.3 Bell
Ring a bell on the client if it has one.



7.4 ServerCutText
Used to send text to client. There is also a similar Message from client to server.


Seminar Report 2010

Chapter 8

ENCODINGS

The various encodings defined in the protocol standard are

8.1 Raw encoding
The simplest encoding type is raw pixel data. In this case the data consists of width-
height pixel values. This is the default encoding used,RFB servers should only produce
raw encoding unless the client specifically asks for some other encoding

8.2 CopyRect encoding
The CopyRect (copy rectangle) encoding is a simple and efficient encoding which can
be used if the client already has the same pixel data elsewhere in its framebuffer.



8.3 RRE encoding
RRE stands for rise-and-run-length encoding and as its name implies, it is essentially
a 2-D analogue of run-length encoding.This is quite complex and is not often used.


Seminar Report 2010

Chapter 9

IMPLEMENTATION


Seminar Report 2010

Chapter 10

CONCLUSION

A Basic Idea of Remote Access and Remote Computing was given .The Various Mes-
sages used in the RFB protocol were speciﬁed in detail and the detailed description
of various working aspects of the RFB protocol were deﬁned. In addition an imple-
mentation example was shown for further understanding of the protocol and also to
make it possible for anyone to program a server or client based on this protocol.


Seminar Report 2010

References

[1] Tristan Richardson; Quentin Staﬀord-Fraser; Kenneth R. Wood; and Andy Hop-
per. Virtual Network Computing IEEE Internet Computing 2

[2] Richardson and Levine. IETF draft , 2009

[3] The RFB Protocol Documentation Version 3.8,,November 2000.


Rfb

More Related Content

What's hot (13)

Viewers also liked (8)

Similar to Rfb (20)

Recently uploaded (20)

Rfb