logging in or signing up rfb protocol larishlr Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINT lite Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: Embed: Flash iPad Dynamic Copy Does not support media & animations Automatically changes to Flash or non-Flash embed WordPress Embed Customize Embed URL: Copy Thumbnail: Copy The presentation is successfully added In Your Favorites. Views: 277 Category: Science & Tech.. License: All Rights Reserved Like it (0) Dislike it (0) Added: November 05, 2011 This Presentation is Public Favorites: 0 Presentation Description seminar ppt Comments Posting comment... Premium member Presentation Transcript REMOTE FRAME “ BUFFER PROTOCOL”: REMOTE FRAME “ BUFFER PROTOCOL”INDEX: INDEX INTRODUCTION DISPLAY PROTOCOL INPUT PROTOCOL REPRESENTATION OF PIXEL DATA PROTOCOL MESSAGES ADVANTAGES DISADVANTAGES REFERENCESINTRODUCTION: INTRODUCTION 1. RFB (“remote frame buffer”) is a simple protocol for remote access to graphical user interfaces. 2. RFB works at the frame buffer level it is applicable to all windowing systems and applications, including X11, Windows and Macintosh. 3. RFB is truly a “thin client” protocol. The emphasis in the design of the RFB protocol is to make very few requirements of the client. 4. The remote endpoint where the user sits (i.e. the display plus keyboard and/or pointer) is called the RFB client or viewer. The endpoint where changes to the frame buffer originate (i.e. the windowing system and applications) is known as the RFB server.Slide 4: 5. The protocol also makes the client stateless. If a client disconnects from a given server and subsequently reconnects to that same server, the state of the user interface is preserved.DISPLAY PROTOCOL: DISPLAY PROTOCOL 1. The display side of the protocol is based around a single graphics primitive: “put a rectangle of pixel data at a given x & y position”. 2. A sequence of these rectangles makes a frame buffer update (or simply update). An update represents a change from one valid frame buffer state to another. The rectangles in an update are usually disjoint but this is not necessarily the case.Slide 6: 3. The update protocol is demand-driven by the client. That is, an update is only sent from the server to the client in response to an explicit request from the client. This gives the protocol an adaptive quality. The slower the client and the network are, the lower the rate of updates becomes. With typical applications, changes to the same area of the frame buffer tend to happen soon after one another. With a slow client and/or network, transient states of the frame buffer can be ignored, resulting in less network traffic and less drawing for the client.INPUT PROTOCOL: INPUT PROTOCOL 1. The input side of the protocol is based on a standard workstation model of a keyboard and multi-button pointing device. 2. Input events are simply sent to the server by the client whenever the user presses a key or pointer button, or whenever the pointing device is moved. 3. These input events can also be synthesized from other non-standard I/O devices. For example, a pen-based handwriting recognition engine might generate keyboard events. REPRESENTATION OF PIXEL DATA: REPRESENTATION OF PIXEL DATA 1. Initial interaction between the RFB client and server involves a negotiation of the format and encoding with which pixel data will be sent. This negotiation has been designed to make the job of the client as easy as possible. 2. The bottom line is that the server must always be able to supply pixel data in the form the client wants. However if the client is able to cope equally with several different formats or encodings, it may choose one which is easier for the server to produce.Slide 9: 3. The most common pixel formats are 24-bit or 16-bit “true color”, where bit-fields within the pixel value translate directly to red, green and blue intensities, and 8-bit “color map” where an arbitrary mapping can be used to translate from pixel values to the RGB intensities. 4. Encoding refers to how a rectangle of pixel data will be sent on the wire. 5. The encoding types defined at present are Raw, CopyRect, RRE, Hextile and ZRLE. In practice we normally use only the ZRLE, Hextile and CopyRect encodings since they provide the best compression for typical desktops.PROTOCOL MESSAGES: PROTOCOL MESSAGES 1. There are three stages to the protocol. 2. First is the Handshaking phase , the purpose of which is to agree upon the protocol version and the type of security to be used. 3. The second stage is an Initialization phase ,where the client and server exchange ClientInit and ServerInit messages.Slide 11: 4. The final stage is the Normal protocol interaction ,the client can send whichever messages it wants, and may receive messages from the server as a result. All these messages begin with a message-type byte, followed by any message-specific data. 5. The following descriptions of protocol messages use the basic types U8, U16, U32,S8, S16, S32. These represent respectively 8, 16 and 32-bit unsigned integers and 8, 16 and 32-bit signed integers. All multiple byte integers (other than pixel values themselves) are in big endian order (most significant byte first).SLIDING WINDOW: SLIDING WINDOW ADVANTAGES- Very efficient for links with low error rates DISADVANTAGES- Not efficient on error prone linksREFERENCES: REFERENCES http://library.thinkquest.org/2705 htp://www.formal.stnford.edu/jmc/whatisai/wahtisai.html http://en.wikipedia.org.org/wiki/Remote Frame Buffer ProtocolSlide 14: THANK YOU You do not have the permission to view this presentation. In order to view it, please contact the author of the presentation.