Rfb
Upcoming SlideShare
Loading in...5
×
 

Rfb

on

  • 768 views

 

Statistics

Views

Total Views
768
Views on SlideShare
768
Embed Views
0

Actions

Likes
0
Downloads
9
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Rfb Rfb Document Transcript

  • RFB PROTOCOL B.Tech Seminar report by Saurabh Santhosh ETAHECS043Department of Computer Science And EngineeringGovernment 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, ThrissurDept. 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 FramebufferUpdateRequest . . . . . . . . . . . . . . . . . . . . . . . . 12 6.4 KeyEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.5 Keysym . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.6 PointerEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7 SERVER TO CLIENT MESSAGES 14 7.1 FramebufferUpdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2 SetColourMapEntries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Dept. 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 22Dept. of CSE, GEC, Thrissur iii
  • Seminar Report 2010 List of Figures 1.1 Working of VNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Dept. of CSE, GEC, Thrissur iv
  • AbstractRemote Desktop Softwares are those softwares which provide Remote Access. RemoteAccess means the ability of a user to log onto a remote computer or network from adistant location. This usually comprises of computers, a Network, and some remoteaccess software to connect to the network. Since this involves clients and servers con-nected across a network,a protocol is essential for efficient communication betweenthem. RFB protocol is one of such protocols which is used by the client and serversfor 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 actuallyworks. This paper also gives a broad idea about the various messages of this protocoland 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 thevarious messages and methods and how this protocol is practically used for gainingremote 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 specifies 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 significance 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 conclusionDept. of CSE, GEC, Thrissur 2
  • 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.Dept. of CSE, GEC, Thrissur 3
  • section 2.1 Seminar Report 2010 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.Dept. of CSE, GEC, Thrissur 4
  • 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.Dept. of CSE, GEC, Thrissur 5
  • 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 offered 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.Dept. of CSE, GEC, Thrissur 6
  • section 4.3 Seminar Report 2010 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 responseDept. of CSE, GEC, Thrissur 7
  • section 4.4 Seminar Report 2010 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.Dept. of CSE, GEC, Thrissur 8
  • 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.Dept. of CSE, GEC, Thrissur 9
  • section 5.2 Seminar Report 2010 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.Dept. of CSE, GEC, Thrissur 10
  • 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.Dept. of CSE, GEC, Thrissur 11
  • section 6.4 Seminar Report 2010 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.Dept. of CSE, GEC, Thrissur 12
  • section 6.6 Seminar Report 2010 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).Dept. of CSE, GEC, Thrissur 13
  • 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.Dept. of CSE, GEC, Thrissur 14
  • section 7.3 Seminar Report 2010 Followed By 7.2 SetColourMapEntries This message is used only when the color map is used ; this message tells the client that the specified 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.Dept. of CSE, GEC, Thrissur 15
  • section 7.4 Seminar Report 2010 7.4 ServerCutText Used to send text to client. There is also a similar Message from client to server.Dept. of CSE, GEC, Thrissur 16
  • 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.Dept. of CSE, GEC, Thrissur 17
  • section 8.3 Seminar Report 2010 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.Dept. of CSE, GEC, Thrissur 18
  • Seminar Report 2010 Chapter 9 IMPLEMENTATIONDept. of CSE, GEC, Thrissur 19
  • section 9.0 Seminar Report 2010Dept. of CSE, GEC, Thrissur 20
  • 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 specified in detail and the detailed description of various working aspects of the RFB protocol were defined. 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.Dept. of CSE, GEC, Thrissur 21
  • Seminar Report 2010 References [1] Tristan Richardson; Quentin Stafford-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.Dept. of CSE, GEC, Thrissur 22