End of session opcode?

[Phil Budne]

I've developed and support a product component based on "VNC
Reflector" (a multipoint VNC proxy) for desktop and application
sharing in an integrated (voice, IM, video) collaboration environment
using a web based client.

Is there any RFB extension that allows a leader/server or viewer to
indicate that they are disconnecting (and why)? I'm frequently called
upon to diagnose session problems, and there is no visible difference
between a leader or viewer voluntarily ending a session and (for
example), the client application crashing.

What I'm looking for is an opcode that can be sent by either the
server or the viewer to indicate they are about to disconnect, and a
reason (a string for why would be sufficient). Different reasons
might be fatal error in application, user stopped application, user
closed viewer window, the shared application window closed.... The
fully enumerated list could be long, and would grow over time, which
is why I think a string (or an "other" code + string) would make
sense.

We don't really care about interoperability, but since our data flows
are otherwise pure RFB, I thought it made sense to ask here first.

ISTR hearing the "Real VNC" guys act as assigned numbers authority...
Are they listening here??

TIA
Phil Budne

[Constantin Kaplinsky]

Hello Phil,

Post by Phil Budne
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.

[Adam Walling]

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)

Post by Constantin Kaplinsky
Hello Phil,

Post by Phil Budne
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
http://www.realvnc.com/mailman/listinfo/vnc-list

[Constantin Kaplinsky]

Hello Adam, Phil,

Post by Adam Walling
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.

[Adam Walling]

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.

Post by Constantin Kaplinsky
Hello Adam, Phil,

Post by Adam Walling
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
-----------------------------------------------------------------