Remote Framebuffer Protocol
| RFB (Remote Framebuffer Protocol) | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Family: | Internet protocol family | ||||||||||||||||||||||||
| Operation area: | Data transfer, screen content, user input |
||||||||||||||||||||||||
| Port: | 5900 / TCP (see text ) | ||||||||||||||||||||||||
|
|||||||||||||||||||||||||
The Remote Framebuffer Protocol ( RFB ) is a network protocol for accessing the graphical user interfaces (GUI) of other computers . It is used by VNC to transmit screen content and user input .
Basic principle
An RFB server offers a so-called "screen". Usually a “ desktop ” or a single program of a graphical work environment that runs on a remote computer or the associated applications are displayed on this . The RFB client usually displays this desktop on the user's workstation computer, receives user input ( keyboard inputs , mouse movements and clicks , etc.) and forwards them to the RFB server, which controls the working environment there.
Since it works on the level of the bitmap-oriented graphics memory ( English framebuffer ), it can be used on any window system such as Windows , Mac OS or X11 . The screen contents are transmitted as bitmaps, whereby usually only the respective changes - in suitable coding, see below - are transmitted to the client. There are color depths of 8, 16 and 32 bits per pixel support the RFB client requests the desired color depth and encoding from the server and the server has to be guided by the wishes of the client, if it supports the desired encoding. This design makes it possible to keep the requirements for the client simple and thus to support the use of thin clients .
RFB connections are stateless , so that connection interruptions or changing of the RFB client are possible without any problems without the associated session being lost. The ultimate goal of RFB and VNC is to support remote work on computers in a uniform working environment.
Port and desktop numbers
In the original Unix version of VNC, each VNC server is its own X server and represents exactly one X desktop ( Xvnc ). The first free X server number is used by VNC by default. If a local X server is already running on the machine, which thus :0occupies the X desktop , VNC gets the desktop :1. The TCP port number occupied by VNC is usually 5901 under Unix. Some VNC servers provide port 5800 or a Java applet with which the desktop can be viewed and controlled with a web browser .
5900 + desktopnummer5800 + desktopnummer
There is usually no local X server running under Windows and Mac OS X , so VNC occupies the desktop and thus the TCP port number 5900. This port is also used by the Unix program x11vnc , which offers the existing local X server as a VNC desktop.
:0:0
Protocol details
Handshake & version IDs
As soon as the TCP connection is established, the server sends the RFB version number it supports to the client, to which the client replies with its protocol version number. The protocol version has the structure major .version minor version . It is assumed that the protocol versions with the same major version are compatible with each other. The largest version number supported by both partners is considered to be agreed for the subsequent connection. However, each communication partner is free to terminate the connection after the protocol version has been exchanged if the negotiated protocol version cannot or should not be used for communication.
The version identifier is always a 12-byte long ASCII string, which is terminated with a LineFeed character. The most common versions are 3.3, 3.7 and 3.8:
| version | Identifier | Identifier (hex) | Released |
|---|---|---|---|
| 3.3 | RFB 003.003\n |
52 46 42 20 30 30 33 2E 30 30 33 0A |
January 1998 by Olivetti Research Laboratories (ORL) |
| 3.7 | RFB 003.007\n |
52 46 42 20 30 30 33 2E 30 30 37 0A |
July 2003 by RealVNC Ltd. |
| 3.8 | RFB 003.008\n |
52 46 42 20 30 30 33 2E 30 30 38 0A |
July 2005 by RealVNC Ltd. |
Some clients incorrectly report a protocol version 3.5. This should be treated like version 3.3 on the server side.
Client authentication
If the client and server have negotiated a compatible RFB version, the server sends the type of authentication it requires from the client. In the original RFB specification two types are defined: "VNC authentication" or "no authentication". However, other types of authentication have been defined by third-party manufacturers. The client decides which of the authentication types offered by the server it wants to authenticate on the server.
initialization
After successful authentication, the client sends a 1-byte “ClientInit” message. This only contains a flag indicating whether the client accepts a "shared" connection, i. This means that possible connections from the server to other clients are allowed or (if the flag is set to 0) should be terminated.
The server then sends a "ServerInit" message. This contains the name of the desktop (which is often derived from the computer name of the server), the size of the desktop (in pixels) and the native color depth and arrangement of the pixels on the server side. The image data are transmitted to the client in this format by default, unless the client requests the data in a different format that is easier for the client to process via a “SetPixelFormat” message.
Data transfer
The client controls whether and when data should be transferred. It sends the local keyboard and mouse input to the server. In addition, it regularly sends “FramebufferUpdateRequest” messages to the server, which then sends the changes to the screen content (since the last FramebufferUpdateRequest) to the client.
In the original RFB version, the movements of the mouse pointer were also sent to the client via normal frame buffer updates. The amount of data to be transferred is quite high and, above all, the associated latencies make operation difficult. With RFB version 3.8 an extension was introduced which allows the mouse pointer to be drawn locally by the client and only the appearance of the mouse arrow and its changes (e.g. when the mouse arrow moves over an input field and then to the I Cursor will be transferred to the client.
Since version 3.8. a change in the size of the desktop will be transmitted to the client. In earlier versions, the server had to terminate the connection to the client, since the size of the desktop could only be transferred to the client in the initialization phase of a connection.
Web links
- RFC 6143 - The Remote Framebuffer Protocol