Phil and Constantin,
I have implemented something similar for the UltraVNC project. It is not in any
official builds yet, but it has worked out fine in our internal projects.
I pasted the relevant portions from rfbproto.h here. It is simple enough and
should be pretty self-explanatory. Note the request/ack approach which works
around misbehaving proxies or systems that might not 'linger' the socket for
outgoing data after it is closed.
It would be nice to standardize this with however TightVNC is handling it;
let's discuss with Constantin.
#define rfbExplicitDisconnect 0x51
#define rfbEncodingExplicitDisconnect 0xC0A1E5CD
typedef struct {
CARD8 type; /* always rfbExplicitDisconnect
*/
CARD8 messageLength; // length of following string (0 if none)
CARD16 flags; // rfbExplicitDisconnectFlags
} rfbExplicitDisconnectMsg;
#define sz_rfbExplicitDisconnectMsg 4
typedef enum {
disconnectAvailable = 0x0000, // no flags, sent by server
as response to rfbEncodingExplicitDisconnect
disconnectRequest = 0x0001,
disconnectAcknowledged = 0x0002,
disconnectAbnormal = 0x8000, // denotes an abnormal
termination (program error) as compared to an intentional disconnect
disconnectMask = 0xFFFF
} rfbExplicitDisconnectFlags;
// when server gets rfbEncodingExplicitDisconnect, it can respond with
// an rfbExplicitDisconnectMsg with the disconnectAvailable flag (basically all
zeros)
// to notify the viewer that it supports this extension.
// when a viewer disconnects, it can send a disconnectRequest to the server,
which can then
// send a disconnectAcknowledged indicating it acknowledged the message (which
is useful when
// going through a proxy / repeater). The same applies if the server is
disconnecting the
// viewer.
// in either case the disconnectAbnormal flag can be set to indicate an error
state.
// if messageLength is set, then a string follows (messageLength number of
chars)
On Apr 21, 2011, at 7:07, Constantin Kaplinsky <co...@tightvnc.com> wrote:
> Hello Phil,
>
>>>>>> Phil Budne wrote:
>
>> Is there any RFB extension that allows a leader/server or viewer to
>> indicate that they are disconnecting (and why)?
>
> We planned to introduce similar protocol extension in future TightVNC
> versions. Indeed, it's a very useful thing to have. However, it's not in
> TightVNC yet.
>
> As for the codes, we've registered just one message code for TightVNC,
> and all our future messages will start with that code. If you are
> interested to co-operate, we could discuss how to implement this
> protocol extension such way that it would be supported in both your
> product and TightVNC.
>
> Just e-mail me if you are interested.
>
> --
> Best Regards,
> Constantin
>
>
> _______________________________________________
> VNC-List mailing list
> VNC-List@realvnc.com
> To remove yourself from the list visit:
> http://www.realvnc.com/mailman/listinfo/vnc-list
_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
