Mailing List Archive

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

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 <const@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

Hello Adam, Phil,

>>>>> Adam Walling wrote:

> It would be nice to standardize this with however TightVNC is
> handling it; let's discuss with Constantin.
>
> #define rfbExplicitDisconnect 0x51

Unfortunately, this will not work in TightVNC, because simply adding a
new message would break RFB protocol compatibility.

In TightVNC, there is a mechanism allowing to register new protocol
messages in 100% compatible way (via "capabilities"). When both sides of
the connection (server and viewer) support TightVNC protocol extensions,
the server tells the client which extended messages it supports. This
allows client and server negotiate their capabilities and use only those
messages that are guaranteed to be supported by the other side.

We plan to implement the message similar to rfbExplicitDisconnect via
capabilities mechanism so that the server would send it only when it
knows this message can be used by the client. And we use 4-byte message
codes in TightVNC for non-standard messages (where the first byte is
always the same and is registered in the standard RFB protocol
specification).

If you are interested to make the message TightVNC-compatible, we will
be glad to cooperate, but we are interested only in solutions that would
work via capabilities and thus would not break compatibility with
standard RFB clients and servers.

--
Best Regards,
Constantin

-----------------------------------------------------------------
TightVNC Weh site: http://www.tightvnc.com/
Follow TightVNC on Twitter: http://www.twitter.com/tightvnc
-----------------------------------------------------------------

_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

I think implementing the TightVNC extensions are the way to go. I would be pleased to collaborate on a standard via that approach. Let me know if/when you have something designed and I can provide any comments.

Is there further documentation on the Tight extensions beyond what is in the TigerVNC community rfb document? I get the general idea, though the tunnels confuse me a bit. Are any implemented and/or documented?

Thanks for all the work you put into this.

On May 5, 2011, at 7:37, Constantin Kaplinsky <const@tightvnc.com> wrote:

> Hello Adam, Phil,
>
>>>>>> Adam Walling wrote:
>
>> It would be nice to standardize this with however TightVNC is
>> handling it; let's discuss with Constantin.
>>
>> #define rfbExplicitDisconnect 0x51
>
> Unfortunately, this will not work in TightVNC, because simply adding a
> new message would break RFB protocol compatibility.
>
> In TightVNC, there is a mechanism allowing to register new protocol
> messages in 100% compatible way (via "capabilities"). When both sides of
> the connection (server and viewer) support TightVNC protocol extensions,
> the server tells the client which extended messages it supports. This
> allows client and server negotiate their capabilities and use only those
> messages that are guaranteed to be supported by the other side.
>
> We plan to implement the message similar to rfbExplicitDisconnect via
> capabilities mechanism so that the server would send it only when it
> knows this message can be used by the client. And we use 4-byte message
> codes in TightVNC for non-standard messages (where the first byte is
> always the same and is registered in the standard RFB protocol
> specification).
>
> If you are interested to make the message TightVNC-compatible, we will
> be glad to cooperate, but we are interested only in solutions that would
> work via capabilities and thus would not break compatibility with
> standard RFB clients and servers.
>
> --
> Best Regards,
> Constantin
>
> -----------------------------------------------------------------
> TightVNC Weh site: http://www.tightvnc.com/
> Follow TightVNC on Twitter: http://www.twitter.com/tightvnc
> -----------------------------------------------------------------

_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list