Ramesh Dharan wrote:
The proper way to use new client message types (which is now
described
in the RFB spec) is to advertise a new pseudo-encoding for
that client
message type and wait for the server to send the
pseudo-encoding back to
the client. That lets the client know that it is safe to use the new
client message type. This is what I'm using for my shared
memory encoding.
Otherwise, there's no way to write a client that works with the
"enhanced" server and a normal VNC server.
Ok, yeah that makes sense. So yeah basically we would need to add new server
encodings for our client->server messages, and then you get the server to
send dummy "ack" messages for each one to say "yes, I understand this message
type"?
Yup.
The mechanism I described above is what the current preferred method
is. If you want, we can bring the topic up with the VNC authors as
AFAIK I'm the only person with a reserved client message type. Of
course, I think using a pseudo-encoding is a perfectly
suitable way to
address this problem.
Yeah the only problem I see with it is that I don't see how the server can
dynamically *change* the set of client messages that it accepts?
To do it in general? Yeah, I don't think there's a solution. Of
course, a SetServerEncodings would introduce a race. What does the
server do if it receives one of the new special client messages after
sending the SetServerEncodings message (but before the client receives
the SetServerEncodings message)?
I think it's easier to just add something to the psuedo-encoding to
allow client messages that make sense to disable to be disabled on a
case-by-case basis.
Regards,
Anthony Liguori
--
Ramesh
