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