Hi,
If you are really trying to do a "4.0" RFB, could you drop in the
additional scaling/resolution capabilities that were added for PalmVNC?
I'd like to see these extended for use in other servers/clients... I get
many requests basically asking for this to be put in, but I can only
work with the Windows server. Again, don't need them to be implemented -
just documented in the "official" RFB spec.
Details are available in the rfbproto.c in the source distro: see
http://www.harakan.btinternet.co.uk/PalmVNC - but here's a summary of
the new messages (working from memory here):
1) Request Scaling: Client sends this to the server to request
server-side image resizing to reduce bandwidth. Takes an integer
parameter that is the requested scale factor (1:1, 1:2, 1:3, 1:7 etc.).
2) Resize Frame Buffer: Sent from server to client to indicate that the
frame size has changed. This could be either a scaling operation (e.g.
1024x768 becomes 512x384) or due to a res change (e.g. to 800x600).
NOTE: This allows a fix for a common problem suffered by Windows
users(resizing server screen size results in loss of connection, server
screen size sometimes resizes when logging in to (at least) NT/2K).
Note that all navigation etc. is done in scaled coordinates - hence the
client doesn't need to know what scale the server is running in, it just
works within the frame buffer dimensions it has been given. All it has
to do is free and reallocate the client framebuffer.
Server Scaling is extemely effective at reducing bandwidth: as the RFB
coding is applied after scaling, you tend to get a major performance
boost. Other nice tricks include having a small "overview" window of the
whole desktop, whilst downloading only the live data for the bit you are
working on (e.g. a 400x300 application window). Again, the performance
boost, especially over low-bandwidth connections, it HUGE if you use a
client that is smart enough to download only a subset of the display.
Cheers,
Chris.
(PS - Only comment on your "4.0" proposal: This will almost certainly
break compatibility with existing clients/servers that look for 3.x;
implementing support for both would increase the size of clients+servers
substantially. Better to arrange your extensions to work as "3.4", which
indicates that it is backward-compatible with 3.3 if that is all the
client or server supports).
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Andrew van der
Stock
Sent: 14 July 2001 19:16
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RFB Protocol 4.0 - encodings wanted
Hi there,
I'm working on a revision to the RFB protocol for authentication and a
few other things. I'd like to see all the other encodings documented,
including the Tridia ones. If you have information on these other
encodings or corrections to the current ones, and would like to see them
fully documented, please contact me with details so they can be
included.
Things I am adding:
* Two new RFB authentication mechanisms
- an uprated version of the current #2 mechanism that doesn't involve
reversible passwords at either end
- a opaque blob authenticator; this will allow OpenSSL/NTLM/Kerberos
implementors to use a standard RFB interchange without revision of the
protocol.
* New login interchange that reduces the information available to
unauthenticated users as well as reducing the inbound load on servers
until after the server has authenticated the client
* optional Below-RFB stream compression indicator (gzip, bzip2)
* optional Lightweight stream encryption support (blowfish, aes, etc)
* Ability for clients and servers to tell each other about their
capabilities
* Add a sound channel to the protocol
All of these do not mean that clients and servers need to implement
these features, I just want to make space. In particular, the old Unix
implementations that forced the getpass() 8 character restriction will
still be able to be insecure. The other platforms will be more secure.
Once I've finished the first draft, I'll be making it generally
available at
http://www.evilsecurity.com/vnc/
for public comment, derision, etc. This page is currently blank. It will
have to wait until I get back to Australia to upload the document.
Once these lists are happy with the revised features, I'd like to pass
the authentication and encryption proposals to secprog@securityfocus and
ask a few experts for their peer review. We are going to get
authentication and encryption right this time.
Andrew
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list to
[EMAIL PROTECTED] See also:
http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
