Intel® Business Client Software Development
Support for Intel® vPro™ software development and technologies associated with Intel vPro platforms.

RFB (VNC) protocol 4.0 specification?

Max
Beginner
2,174 Views
The AMT KVM server advertises RFB protocol 4.0
However 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?
0 Kudos
12 Replies
Ylian_S_Intel
Employee
2,174 Views
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.
0 Kudos
Max
Beginner
2,174 Views
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.
0 Kudos
Gael_H_Intel
Moderator
2,174 Views
Hi Max,

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

0 Kudos
Max
Beginner
2,174 Views
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.
0 Kudos
Gael_H_Intel
Moderator
2,174 Views
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...)
0 Kudos
Max
Beginner
2,174 Views
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.

0 Kudos
Max
Beginner
2,174 Views
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.
0 Kudos
Gael_H_Intel
Moderator
2,174 Views
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.)
0 Kudos
Gael_H_Intel
Moderator
2,174 Views

Max:

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

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

0 Kudos
Max
Beginner
2,174 Views
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)
0 Kudos
Gael_H_Intel
Moderator
2,174 Views
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 Documentation
The documentation is in the html folder

Protocol extensions

The 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 decoders

A 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 Transports

Internally, 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.

0 Kudos
Max
Beginner
2,174 Views
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).
0 Kudos
Reply