- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You would need to stick with 3.8 version for now (unless you can sign a deal with RealVNC...)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
![](http://s15.postimage.org/jqdnwmjmj/amt_bw_use.png)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
![](/skins/images/D2683F18326913BBA0436CB7114DD569/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page