-
How do I make VNC go faster?
-
We find VNC to be perfectly acceptable as our normal method of
accessing Unix desktops on a daily basis. This is over a 10 Mbit/s
ethernet on reasonably modern machines, using the X or Win32 viewer.
Because Windows gives us fewer hints about what it's doing, and
because we don't have the source code for Windows in the same way that
we do for X, the WinVNC server has to work harder to find out what's
changed, and so a really fast machine should make a big speed
difference. For more information about how the Windows server works,
see the WinVNC documentation. But if you've
been disappointed by the speed of the Windows server, don't give up.
We're improving it gradually, but it'll be a while before it's as fast
as on Unix.
There are several things that can slow any VNC session
down, however, and you may like to consider these if you find it too slow:
-
Unusually 'busy' desktops. The VNC protocol is very efficient at
rendering areas of a single colour, such as you generally find on window
title bars, scrollbars, backgrounds of pages etc. But if, for example,
you have pretty 24-bit photographs of your girlfriend as your screen background,
or dithered title-bars on your windows, you may pay a price for the aesthetics.
A
colourful or patterned desktop background will probably slow down VNC more
than any other single factor. We have some suggestions on
speeding
up the twm window manager, some of which will also apply to other environments.
-
Hi-colour desktops. Don't use 24-bit colour if you can use
16 or 8 equally well. Remember, on Unix you can run multiple servers, so
I have a big 16-bit desktop for normal work and a small 8-bit one for when
I log in from home. The server can send out a wide range of pixel
formats, and some viewers will allow you to request a specific format for
that session. On the Windows viewer, for example, if you click Options...
when making the connection, you can request only 8-bit pixels from the
server - useful if the network gets slow. If you are using a modem,
I recommend changing the shortcut in the Start menu to include the /8bit
option - this will then be the default. Similarly, if you regularly
connect to a remote WinVNC server, consider whether you could run happily
at lower resolution. A 1280x1024 screen has more then 4 times as many pixels
as a 640x480 one, and if all you are doing is checking a printer queue
you probably don't need them all! Note, though, that on WinVNC, 16-bit
colour is usually the best to use. See below.
-
Elderly graphics cards or drivers may make quite a difference; this is
a graphics-intensive application! On Windows the graphics system
on the server will affect the speed as well as the one on the viewer.
-
Some applications are not very economical about redrawing their display.
Early versions of Unix Netscape, for example, tended to draw everything
twice when scrolling, which did nothing to help the smoothness under VNC.
X11Amp flashes its display very fast when in 'pause' mode.
-
Some Java Virtual Machines are particularly fast at reading from the network
and particularly slow at drawing to the screen, or vice versa. With
the Java viewer it is worth experimenting with the encodings available
from the Options menu, as we sometimes find big differences in speed.
-
If you are connecting to WinVNC, don't change the default settings in the
Properties box unless you need to.
-
All the standard clients can do local rectangle copying, and this generally
means that dragging a full window on X is much faster than dragging its
outline. If your window manager allows this, it may speed things
up. Roman Mitnitski also reports that when he increased the
mouse dragging threshold (-t option of the server) the performance was
improved.
-
Generally, with WinVNC, use 16-bit colour (65536 colours) on the server
if you can. 16-bit is almost always the best depth to use, because:
-
256-colour screens have to be palette-converted before they can be transmitted
to truecolour clients. Only if the client is 256-colour palette- based
will you see any performance increase. Even if the client is 256 colour
truecolour, it'll have to convert via a 32-bit truecolour palette!
-
24-bit screens have to be specially munged via 32-bit since VNC's internal
colour-handling routines don't work with 24-bit directly.
-
24 and 32-bit screens have to have each pixel looked up in three tables
to get the converted value.
-
Graphics cards claiming to do 24-bit often actually do 32-bit with munging
- this in many cases makes 24-bit slower just for general use than 32-bit!
-
Finally, 16-bit involves no palette processing and a single lookup in a
cached src_format to dest_format table to convert the pixels.
On slow links, you may also want to use some software to compress the data
between the two ends. SSH is good for this. See the section on security
below.
- Will VNC work through a firewall?
- It depends on your firewall, and whether you want to
access a server inside your firewall from elsewhere, or a server outside
your firewall from inside.
- Generally firewalls are designed to prevent incoming
connections except to certain well-known machines and ports. If you
can configure these to include your VNC server, then you will be able to
access it from anywhere in the world. There is a good argument to
be made for the fact that VNC is less of a security risk than X, so if
your site doesn't allow X in or out it may still allow VNC.
- Many modern firewalls will allow outgoing connections
initiated from inside, so you can often access servers on outside machines.
It is straightforward, for example, to recompile the viewer source to include
SOCKS support, or to make other special arrangements. See the contribs
page.
- It's a pity that Java within a browser doesn't automatically
use SOCKS if the browser is configured to use it. There's probably
Java SOCKS support out there somewhere...
- If your internet access is through a router which does
Network Address Translation, you may be able to configure the router to
redirect particular incoming ports to particular machines. So you could
run WinVNC with a display number of 0 on machine snoopy, and with display
1 on machine woodstock, then set your router to send port 5900 to snoopy
and 5901 to woodstock. See below for information on the other port
numbers used by VNC.
-
Which TCP/IP ports does VNC use?
- A VNC server listens on two ports. The exact port numbers
depend on the VNC display number, because a single machine may run multiple
servers. The most important one is 59xx, where xx is the display number.
The VNC protocol itself runs over this port. So for most PC servers, the
port will be 5900, because they use display 0 by default.
- In addition, VNC servers normally have a small and
very restricted web server built in, which allows you to connect a browser
to them and use the Java viewer. This runs on port 58xx. Note
that this is the HTTP port used for downloading pages and applets, but
once the applet is running it uses 59xx for VNC just like any other viewer.
- The servers can be changed to listen on other ports
if, for any reason, these are not suitable for you. See the server's
documentation
for more details. Most of the viewers, if given a display number
larger than 99, will interpret it as a direct port number and will not
add 5900. See also the next question.
- If you are running a viewer in 'listening' mode, where
it accepts connections initiated by the server, it will listen for incoming
VNC on port 5500.
- Can I run VNC over a port normally used for a standard service? (eg. port 21, or port 80)
- In rare circumstances, people may want to do this, perhaps because they have a firewall which only allows connections to certain ports. This can be done, at least for the Windows and Unix servers (see their documentation), but the following points need to be borne in mind:
- On some systems (eg. most forms of Unix), ordinary users are not
allowed to run servers on ports below 1024.
- You obviously can't run a VNC server on a port that's already
being used for other things.
- Many VNC servers use two ports: one for the VNC server, and one
for the HTTP server that provides the Java applet (see previous
question). If you plan to use the Java viewer, you may want to change
both. Not all servers will allow this at present.
- You need to tell the viewer the right display number. Normally,
display numbers come between 0 and 99. If you specify any number
smaller than 99, the viewers add 5900 to get the port number. If you
specify a larger number, the viewers take it as a port number
directly. So how do you use port numbers lower than 99? You have to
specify a negative display number! For example, to connect to a
server running on port 80 on machine 'snoopy':
vncviewer snoopy:-5820
because -5820 + 5900 = 80. This may not work with all viewers, but Unix and Windows seem to be fine.
-
How secure is VNC?
- Access to your VNC desktop generally allows access
to your whole environment, so security is obviously important. VNC uses
a challenge-response password scheme to make the initial connection: the
server sends a random series of bytes, which are encrypted using the password
typed in, and then returned to the server, which checks them against the
'right' answer. After that the data is unencrypted and could, in theory,
be watched by other malicious users, though it's a bit harder to snoop
a VNC session than, say, a telnet, rlogin, or X session. Since VNC
runs over a simple single TCP/IP socket, it is easy to add support for
SSL or some other encryption scheme if this is important to you, or to
tunnel it through something like SSH.
SSH allows you to redirect remote TCP/IP ports so that all
traffic is strongly encrypted, and this can be combined with VNC.
SSH can also compress the encrypted data - this can
be very useful if using VNC over slow links. See the 'Using SSH with VNC' page.
- While we're on the subject of security, you should
also be aware that only the first 8 characters of VNC passwords are significant.
This is because the 'getpass' call used in the Unix server to read a password
has this restriction, and the other platforms have been made compatible
with this.
-
Ray Jones <rjones@pobox.com>
has
built a version of VNC which uses SSLeay public key encryption, and Wolfram
Gloger <wmglo@dent.med.uni-muenchen.de>
has built Xvnc with the TCP Wrapper library, allowing you more control
over which hosts are allowed to connect. See the contribs
page for details.
- Are you going to make it more secure?
- We do hope eventually to add better security to VNC, but
there's also a good argument for not doing so. If security is
a concern, it can be better to use a single system such as SSH or
FreeS/WAN to encrypt all your traffic, rather than relying on the
individual packages to do the right thing. Then, if you decide in a
year's time that one system is too easily crackable, you can replace
it yourself and all of your communications will benefit. It may also
be easier to fit in with corporate security systems this way.
- Could you do file transfer (e.g. by drag & drop) between the two ends?
-
It's certainly possible, but we aren't going to do it. File transfer
seems simple, but is actually rather complicated to do in a cross-
platform way. Some examples: How do you map filenames between
platforms with wildly different naming conventions? How do you cope
with running out of disk space? What about permissions? How do you
do it on platforms which don't have a concept of drag and drop? Can you interrupt the transfer if it's taking too long? Can you restart it if it gets interrupted?
Since there are a very large number of perfectly good systems out
there for transferring files over IP, we aren't planning to
incorporate it in VNC. It would probably more than double the size of
the code, and would introduce all sorts of issues that we, quite
frankly, aren't interested in! So use the standard file transfer built
into Windows, or use FTP, or netcat, or the web, or rcp, or ssh, or...
- Are you planning support for AIX, EPOC,HP-UX, SGI, Win 3.1,
or my favourite platform ?
- We have provided VNC on all the platforms we use here, and
it's difficult to provide binaries for anything we don't have, and it
takes a while to get up to speed on new platforms. Information about
third-party ports of VNC to a large number of other platforms can be
found on the 'contribs' page, so check
there first. Remember that a viewer is available for any platform
which runs Java, though the speed may vary quite a bit. But for many
platforms it should not be difficult to compile at least the
viewer. If anyone tailors the sources for a particular platform we
will happily either incorporate the changes in the main source
distributions or make the patches available from our site.
-
Would things work better if you compressed the stream?
VNC incorporates really quite efficient compression
in the sense that we generally send a tiny fraction of the raw data, probably
something like 1/20 on average. The details are in the protocol spec if
anyone's interested. On a couple of test screen dumps we found that
the Hextile encoding was more efficient than GIF! I don't know whether
this is true in general.
But we haven't done more general encoding after that;
we've tended to the view that (a) it might introduce too much latency and
(b) most modems compress pretty well anyway. We are planning
some zlib-compression experiments in the near future to see how this affects
things. Because different bits of the screen can be sent using different
encodings, the server could, in theory, detect that one bit would be most
efficiently sent as JPEG, while another would be better hextiled.
The question is always how much work it's worth doing
at the server to find this out. To some degree you can control this
already, because the viewers allow you to specify your preferred encoding.
Under X, if your viewer and server are on the same machine the viewer will
use the raw encoding by default, otherwise it will use hextile. You
may find that by selecting different encodings on the command line you
get better performance.
See also the suggestions above about using ssh, which also
provides compression.
-
Have you thought about caching bits of the screen at the viewer end?
- Yes, that could also be good. You could have an off-screen
cache in the viewer and the server could copy things from there to the
screen. Management of this would add a certain amount of complexity,
though.
- Since there is already a CopyRect primitive in VNC,
an alternative approach would be to copy updates from another part of the
screen if they already exist there, rather than resending them. Again,
to make the server find out efficiently when this is worth doing would
be an interesting challenge, and volunteers for the project are welcome!
-
Can I use VNC over a modem without using TCP/IP?
- Not at present. VNC could run over other transports such as
RS232, firewire, USB, modems, IrDA etc, in fact, anything which gives
a reliable 2-way connection. At present we just use TCP/IP, because
it's convenient, ubiquitous, and easy to route. This means that you
can use VNC over anything which supports TCP/IP, so using it over a
modem is just the same as any other network, once you have Dial-Up
Networking set up. If you need to communicate directly between two
machines without going via the internet/intranet, then set up a remote
access server on one and dial in from the other.
-
Does VNC have any Y2K (Year 2000) bugs?
- The WinVNC server and Windows viewer have been tested
on a PC with its date running through the 2000 boundary without any problems,
so unless the underlying OS or BIOS has difficulties, VNC on a PC should
be fine. The VNC part of the X-based Unix VNC server only uses dates
when writing the log files; the logfile entries are timestamped with a
two-digit year, but the format is easy to change if required and the entries
are not intended to be machine-readable. The developers of the XFree86
server on which Xvnc is based state that there are no Y2K problems (see
http://www.xfree86.org/FAQ/). We therefore issue the standard disclaimer:
we believe the VNC code, in its entirety, to be free from Year 2000 problems,
subject to the other components of the systems on which it is running.
-
Any other tips?
- Several people have indicated that they have to use
Windows occasionally but prefer to use Unix most of the time, and so want
to access a PC under the desk from the Unix box.
-
Here's a suggestion: all other things being equal,
I recommend using the Windows box to view the Unix machine rather than
the other way around. This is chiefly because Windows generally works
better as a client than as a server, and also because PC graphics cards
are often better than those in Unix workstations. Remember, you can
create a VNC session of any size and pixel depth you like.
If you're very anti-Windows you can make your VNC desktop
the same size as the local screen and set the taskbar to 'Auto hide' and just
pretend you're on an X terminal, but pop up the Start menu when you have
to use PowerPoint.... The Windows viewer also now has a proper
'full-screen mode', so you don't even need to bother with auto-hide.
-
You misspelled 'organization' on the download page!
- No we didn't. We spell it like that in the UK.
Actually, we spell it both ways, but the 's' spelling is more common, despite
what the OED says! Now, as for 'misspelt'...