RFB (VNC) protocol 4.0 specification?

RFB (VNC) protocol 4.0 specification?

The AMT KVM server advertises RFB protocol 4.0However the latest published RFB protocol specification seems to be 3.8 (http://www.realvnc.com/docs/rfbproto.pdf)Is there any technical documentation listing the protocol differences between the non-standard 4.0 protocol you use, and vanilla 3.8 RFB?

13 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Interesting, the guys at RealVNC.com are in charge of the specification so hopefully they would know. In general, a VNC client can respond to a "4.0" version number with "3.8" back and you should be ok. Still, if anyonw finds out anything, I would be interested.

Yes, I did get it to work with RFB 3.8, but only with 8-bit color depth.If you tell the server you want 24-bit (like most clients do by default) the server disconnects straight away.(It does also seem to advertise 16-bit true color, but the client is not able to support that natively.)Was wondering if RFB 4.0 perhaps supported some additional image/encoding formats.

Hi Max,

Have you checked out this website "The RFB Protocol?"

From your link:

The only published protocol versions at this time are 3.3, 3.7, 3.8 (version 3.5 was wrongly reported by some clients, but this should be interpreted by all servers as 3.3).

So it does not incorporate any information about 4.0 either.

Hi - the 4.0 protocol is actually proprietary. 3.8 is the most current public version. You would need to have the license for the dllfor 4.0 but you would not get the license to write code for the 4.0 version.

You would need to stick with 3.8 version for now (unless you can sign a deal with RealVNC...)

Do you also effectively need the license to get any type of compression?

Receive only RAW frames, even though the client tells the server it can use the standard 3.8 hextile and rre encodings.Easily consumes 940 KiB/s (7.5 mbit) bandwidth just scrolling through a simple text menu.

A somewhat related question.Does anyone know if the AMT's implementation of the TLS encryption protocol supports the optional zlib compression?
Might be able to modify my proxy server code so that it connects to the TLS redirection port 16995, if I can save some bandwidth that way.

You might want to try the RealVNC Mailing List- these questions are beyond what we handle in this discussion forum. (Unless we have a developer out there who knows and wants to chime in.)


you mean that during TLS handshake sides agree also on compression method of

doesn't support it, I don't know if other TLS implementations support it.

You might want to try the RealVNC MailingList

Be aware that the questions are not about the VNC protocol itself, but rather about the limitations of the specific implementation by Intel AMT.

My point of view is that we are an Intel customer, and have nothing to do with RealVNC.

Intel puts in their advertising material that they support the RFB protocol (which is definitely a unique selling point over other properaitary solutions)but it seems only a subset of the protocol is supported.
E.g. no compression (at least not one of the standard flavors that are part of the 3.8 standard). Making it unsuitable for use over the Internet.

Do you mean that during TLS handshake sides agree also on compression method of Zlib?

Yes. TLS can handle compression transparently of the protocol it is tunneling.
(I called the compression method zlib, but official name seems "deflate". http://www.ietf.org/rfc/rfc3749.txt )

AMT doesn't support it, I don't know if other TLS implementations support it.

Too bad.
(As far as other TLS implementations go: a lot of software uses the OpenSSL library, and that uses compression by default if the zlib library is present on the system)

Ok - as it turns out, we do have a RealVNC SDK folder in the AMT SDK.
The KVM Control Sample documentation is located at:
\DOCS\KVM\KVMSampleHTMLDoc.zip. to access the documentation, unzip this file and open Index.html in the top directory (KVMSampleHTMLDoc).
\DOCS\KVM\RealVNC SDK DocumentationThe documentation is in the html folderProtocol extensionsThe SDK provides the ability for applications to define their own protocol extensions. These allow the application to exchange short messages with the VNC server to which it is connected.

Protocol extensions are supported only for VNC sessions using RFB 4.0 or later.

To configure the SDK to use a protocol extension, you must provide a VNCViewerProtocolExtensionMessageCallback when you callVNCViewerCreate(), and then callVNCViewerRegisterProtocolExtension()in or after the VNCViewerServerInitCallback.

To send a protocol extension message, callVNCViewerSendExtensionMessage().

Your VNCViewerProtocolExtensionMessageCallback will be invoked whenever a protocol extension message is received for an extension that you have registered.

Custom rectangle decodersA VNC server send sends screen updates to the VNC viewer in Rectangle (RFB 4) or FrameBufferUpdate (RFB 3) protocol messages. The payloads of these messages contain pixel data that has been encoded in a variety of ways that are designed to reduce the required bandwidth. (You can think of an RFB encoding as being a compression algorithm for video data.)

The SDK provides the ability for applications to replace or extend the set of encodings that it uses. This allows for an application to compensate for a bugged server-side encoder, or to add support for entirely new encodings.

To configure the SDK to use a custom decoder, you must provide a VNCViewerRectangleDecodeCallback when you callVNCViewerCreate(), and then, before callingVNCViewerStart(), callVNCViewerRegisterRectangleDecoder()for each encoding that the callback will handle.

For for information on the built-in RFB encodings, see the RFB 4.0 Specification or the RFB 3.8 Specification.

Custom TransportsInternally, the SDK uses TCP socket connections to transport RFB data. A set of callbacks allow the replacement of the internal default transport layer with any other.

To configure the SDK to use a custom transport, you must provide all of the following callbacks when you callVNCViewerCreate(): VNCViewerTransportOpenCallback, VNCViewerTransportCloseCallback, VNCViewerTransportSendCallback, and VNCViewerTransportRecvCallback. The open callback will be invoked at the beginning of a thread of execution, i.e. shortly afterVNCViewerStart()is called. The close callback will be invoked upon closure of the connection, either as a result of a call toVNCViewerStop()or due to an external disconnection event.

VNCViewerTransportOpenCallback()will be passed a pointer to the Context data set by calls to VNCViewerSetContext; this can be used to identify the server endpoint, (for example, a name and port number could be stored in the Context data for retrieval by the open callback). If desired, the same Context data can be used to identify the connection to all subsequent Send, Recv and Close callbacks in a similar manner. VNCViewerTransportOpenCallback implementations should return appropriate VNCViewerTransportResult values for the type of transport implementated, but at a minimum the open callback must support returning VNCViewerTransportResultSuccess and VNCViewerTransportResultFailure.

VNCViewerTransportSendCallback and VNCViewerTransportRecvCallback implemenations should return VNCViewerTransportResultFailure or VNCViewerTransportResultSuccess as appropriate, aside from cases where the read or write attempt would block; the function should then return VNCViewerTransportResultWouldBlock, with a length value of 0 in the case of a blocked read. In order to indicate to the SDK when an external read, write or close event has occurred/is ready, the application should call the method VNCViewerTransportEvent with one of the VNCViewerTransportStatus values as appropriate.

For for information on the built-in RFB encodings, see the RFB 4.0 Specification or the RFB 3.8 Specification.

The 4.0 specification that is not public?

I do support the hextile and rre encodings mentioned in the 3.8 specification, and advertise that to the server.
However the server chooses to only send uncompressed (raw) frames. Making me think all other 3.8 encodings have been intentionally disabled on the AMT server side. (or to put it more bluntly: I would love to be proven wrong, but to me it looks like the AMT server's 3.8 support was crippled to make VNC client products by other vendors look bad, and make 4.0/RealVNC look superior)

The custom transport/decoder stuff only applies when you want to use that SDK to connect to other VNC servers (not the Intel AMT server).

Leave a Comment

Please sign in to add a comment. Not a member? Join today