From: Johannes Schindelin <Johannes.S<chindelin@gm...> - 2005-09-28 17:28:42
thanks to Rohit Kumar, LibVNCServer now has a proper method to
extend the RFB protocol!
To do this, you provide an instance of the struct "rfbProtocolExtension"
via rfbRegisterProtocolExtension(). The struct is made up of several hooks
which are called at several stages if they are not NULL.
Example: You want to provide a new client message type. Pick a client
message number which is not taken by the known RFB protocols (I try very
hard to collect them and put them into rfb/rfb.h, even if not all are
implemented in the library yet). Provide a handler for these messages,
create an rfbProtocolExtension struct, which has only the appropriate
member set ("handleMessage"), and register the extension.
As of now, you can provide hooks at the following stages: when a new
client is connected, when the client just sent the InitMessage, when the
client sent a normal message which is not handled by LibVNCServer, when
the client closes, when the usage is printed, and when a command line
argument was passed which LibVNCServer does not no about.
Beware! You should always keep the RFB protocol clean, i.e. you should
provide a means for the client to say that the server supports that
extension so that custom clients do not annoy non-LibVNCServer servers by
sending them those requests (which they don't understand). I will detail
how to do that below.
Beware also! The protocol extension method is versatile enough to obsolete
the processCustomClientMessage() method. Therefore this will go soon.
Also, the backchannel message system will eventually be killed, or ported
to the new interface (I haven't decided yet if it is worthwhile to be
Also note that the extension interface is not yet complete. For example, I
want to add another hook to handle the SetEncodings message with
PseudoEncodings yet unknown to LibVNCServer.
Now, how to keep the RFB protocol clean? I.e. how to tell the client it is
safe to send those new custom messages? There are two methods: you can
imitate TightVNC's file transfer extension. The client sends a special
security type, and this enables the file transfer extension (see the file
I do not like that method particularly, because a file transfer is no
security type! However, the other method, namely to add a new
PseudoEncoding, is probably no better.