1.

INTRODUCTION
RFB (remote framebuffer) is a simple and efficient protocol.It provide remote access to graphical user interfaces. Because it works at the framebuffer level it is applicable to all windowing systems and applications, including X11, Windows and Macintosh. RFB is the protocol which is used in Virtual Network Computing (VNC). The two endpoints in the RFB protocol are referred to as the client and the server. The remote endpoint where the user sits (i.e. the display plus keyboard) is called the RFB client or viewer. The endpoint where changes to the framebuffer originate (the windowing system and applications) is known as the RFB server.

RFB is truly a thin client protocol. 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.

2.BASIC PARTS OF RFB PROTOCOL

The basic parts of RFB protocol contains the display and the input protocol. 2.1 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.

2.2 Input Protocol - based on a normal workstation model of a keyboard and multibutton pointing device. Every keypress and mouse events and transferred and simulated at the remote site.

3. 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. The server must 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. So this protocol is called a thin-Client Protocol. Pixel format refers to the representation of individual colours by pixel values. The most common pixel formats are 24-bit or 16-bit true colour, where bit-fields within the pixel value translate directly to red, green and blue intensities, and 8-bit colour map where an arbitrary mapping can be used to translate from pixel values to the RGB intensities. Encoding refers to how a rectangle of pixel data will be sent on the wire. Every rectangle of pixel data is prefixed by a header giving the X,Y position of the rectangle on the screen, the width and height of the rectangle, and an encoding type which specifies the encoding of the pixel data. The data itself then follows using the specified encoding.The encoding types defined at present are Raw, CopyRect, RRE, Hextile and ZRLE.

4. PROTOCOL MESSAGES
The RFB protocol can operate over any reliable transport, either byte-stream or messagebased. It is used over a TCP/IP connection. Three stages of the RFB protocol are. I. Handshaking phase : The purpose of which is to agree upon the protocol version and the type of security to be used.

II.

Initialization phase : Where the client and server exchange ClientInit and ServerInit messages. Normal protocol interaction : The client can send whichever messages it wants, and may receive messages from the server as a result.

III.

5.HANDSHAKING MESSAGES
ProtocolVersion Handshaking begins by the server sending the client a ProtocolVersion message. This help the client to know which is the highest version number of RFB protocol supported by the server. Then client replies with a similar message giving the version number of the protocol which should actually be used . The published protocol versions at this time are 3.3, 3.7, 3.8. The ProtocolVersion message consists of 12 bytes interpreted as a string of ASCII characters in the format "RFB xxx.yyy\n" where xxx and yyy are the major and minor version numbers, padded with zeros. No.of bytes 12 Value "RFB 003.007\n" (hex 52 46 42 20 30 30 33 2e 30 30 37 0a)

6. SECURITY
If the protocol version has been decided, the server and client must agree on the type of security to be used on the connection. The server lists the security types which it supports: No. of bytes 1 number-of-security-types U8 U8 array Type [Value] Description number-of-security-types security-types

If the server listed at least one valid security type supported by the client, the

client sends back a single byte indicating which security type is to be used on the connection: No. of bytes 1 Type [Value] U8 Description security-type

If number-of-security-types is zero, then for some reason the connection failed if the server cannot support the desired protocol version. This is followed by a string describing the reason . No. of bytes 4 reason-length Type [Value] U32 U8 array Description reason-length reason-string

The server closes the connection after sending the reason-string.

7. INTIALISATION MESSAGES
Once the client and server are sure that theyre happy to talk to one another using the agreed security type, the protocol passes to the initialisation phase. The client sends a ClientInit message followed by the server sending a ServerInit message. 7.1 ClientInit No. of bytes 1 Type U8 [Value] Description shared-flag

Shared-flag 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 this client by disconnecting all other clients 7.2 ServerInit After receiving the ClientInit message, the server sends a ServerInit message. This tells the client the width and height of the servers framebuffer, its pixel format and the name associated with the desktop:

No. of bytes 2 2 16 4 name-length

Type U16 U16

[Value]

Description framebuffer-width framebufferheight server-pixel-format name-length name-string

PIXEL_FORMAT U32 U8 array

8.CLIENT TO SERVER MESSAGES

The client to server message types defined in this document are: Number 0 2 3 4 5 6 8.1 SetPixelFormat This Message is used to set the format in which pixel values should be sent in FramebufferUpdate messages. If the client does not send a SetPixelFormat message then the server sends pixel values in its natural format as specified in the ServerInit message. 8.2 SetEncodings This Message is used to set the encoding types in which pixel data can be sent by the server. In addition to genuine encodings, a client can request pseudoencodings to declare to the server that it supports certain extensions to the protocol. A server which does not support the extension will simply ignore the pseudo-encoding. The server may or may not choose the encodings suggested by the clients.This supports backward compatibility. Name SetPixelFormat SetEncodings FramebufferUpdateRequest KeyEvent PointerEvent ClientCutText

8.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. 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. 8.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 . 8.4.1 Keysym Key name BackSpace Tab Return or Enter Escape Keysym value 0xff08 0xff09 0xff0d 0xff1b

For most ordinary keys, the keysym is the same as the corresponding ASCII value. 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. 8.5 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). 8.6 ClientCutText The client has new ISO 8859-1 (Latin-1) text in its cut buffer. Ends of lines are represented by the linefeed / newline character alone.

9. SERVER TO CLIENT MESSAGES

The various server to client message types defined are Number 0 1 2 3 Name FramebufferUpdate SetColorMapEntries Bell ServerCutText

Before sending new messages a server must have determined that the client supports the relevant extension by receiving some confirmation from the client usually a request. This is done with the help of message specified earlier. 9.1 FramebufferUpdate A framebuffer update message is used to reproduce the GUI at the client computer. It is sent in response to a FramebufferUpdateRequest from the client. Note that there may be an indefinite period between the FramebufferUpdateRequest and the FramebufferUpdate.. A framebuffer update consists of a sequence of rectangles of pixel data which the client should put into its framebuffer. 9.2 SetColourMapEntries This message is used only when the pixel format uses a colour map, this message tells the client that the specified pixel values should be mapped to the given RGB intensities. 9.3 Bell Ring a bell on the client if the number of bytes field in the message has one. 9.4 ServerCutText Used to send text to client. There is also a similar Message from client to server. The server has new ISO 8859-1 (Latin-1) text in its cut buffer. Ends of lines are represented by the linefeed / newline character .

10. ENCODINGS
The encodings defined in this document are Number 0 1 2 5 16 -239 -223 10.1 Raw encoding The simplest encoding type is raw encoding. In this case the data consists of widthheight pixel values. This is the default encoding used,RFB servers should only produce raw encoding unless the client specifically asks for some other encoding. The simplest encoding type is raw pixel data. In this case the data consists of widthheight pixel values (where width and height are the width and height of the rectangle). 10.2 CopyRect encodingThe 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. 10.3 RRE encoding RRE stands for rise-and-run-length encoding. Its name implies, it is essentially a 2-D analogue of run-length encoding. This is quite complex and is not often used. Name Raw CopyRect RRE Hextile ZRLE Cursor pseudo-encoding DesktopSize pseudo-encoding

10.4 Hextile encoding Hextile is a variation on the RRE idea. Rectangles are split up into 16x16 tiles, allowing the dimensions of the subrectangles to be specified in 4 bits each, 16 bits in total. 10.5 ZRLE encoding ZRLE stands for Zlib1 Run-Length Encoding, and combines zlib compression, tiling, palettisation and run-length encoding. On the wire, the rectangle begins with a 4-byte length field, and is followed by that many bytes of zlibcompressed data. A single zlib stream object is used for a given RFB protocol connection, so that ZRLE rectangles must be encoded and decoded strictly in order. 10.6 Cursor pseudo-encoding This encoding scheme is a type of pseudo-encoding. A client which requests the Cursor pseudo-encoding is declaring that it is capable of drawing a mouse cursor locally. This can significantly improve perceived performance over slow links. 10.7 DesktopSize pseudo-encoding This is an another type of pseudo encoding. A client which requests the DesktopSize pseudo-encoding is declaring that it is capable of coping with a change in the framebuffer width and/or height. The server changes the desktop size by sending a pseudo-rectangle with the DesktopSize pseudo-encoding as the last rectangle in an update.

11. CONCLUSION
The Various Messages used in the RFB protocol were specified in detail and the detailed description of various working aspects of the RFB protocol were defined. This enables remote users to share the desktop of the server either exclusively or on a sharing basis. RFB (Remote Frame Buffer) is a simple protocol for remote access to graphical user interfaces. Originally the RFB protocol was developed as a means of interacting with applications from an ATM network display device called the Videotile. The same basic RFB protocol is also used in the Virtual Network Computer.

10

12. REFERENCES

By Magued Iskander, Vikram Kapila, Mohammad A. Karim. Technological Developments in Education and Automation www.tigervnc.org.

11