This page covers many different aspects of "VNC", which is comprised
of the RFB (Remote Frame Buffer) protocol, and software implementing
same. The emphasis is on Unix, Linux and Palm implementations, but
there are small bits about microsoft windows as well.
This page was majorly overhauled Sun Dec 5 PST 2004.
Fri Jan 14 20:42:50 PST 2005: Added a VNC viewer written in python.
Thu Dec 23 17:21:58 PST 2004: Added (more) information about building
TightVNC on AIX 5.1.
Wed Jan 12 15:35:37 PST 2005: Added a set of patches for making a
development version of TightVNC build on Fedora Core 3.
Vino is
a gnome-centric VNC server implementation. Apparently it
is to be bundled with RHEL 4, and appears to be a part of
FC3. It looks like it's mostly for making it so that an enduser
can conveniently share their desktop with an admin, to facilitate
problem solving. The server includes encryption, and the package
includes (included) a java client that does as well.
Vino may someday be split into two separate packages: one for the
client, one for the server. Looks like the java client that
supports encryption has been removed from the latest sources!
TightVNC. The most
popular alternative implementation of VNC. Supposed to include
jpeg compression, meaning "fast but lossy".
UltraVNC is a popular implementation, but seems to be just for
windows - no Linux, no Unix - a search of their mailing list
suggests not even PalmOS.
Tridia
(developvnc.org)
appears to have been very interesting at one time, but the site seems
moribund now. At least at one time, they had an opensource
version, as well as a commercial version called "Tridia Pro".
DirectVNC
is a VNC client for the Linux framebuffer (no X required). I'm not sure
if this was DirectVNC's fault, or TightVNC's fault, but my
TightVNC servers kept getting messed up, whether I tunneled
through zebedee or ssh.
fbvnc is
intended for svgalib. Nice keyboard! AA Scaling... I'm not sure
if this was fbvnc's fault, or TightVNC's fault, but my
TightVNC servers kept getting messed up, tunneling
through zebedee.
svncviewer - this proved awkward to compile against tightvnc
1.3dev5_unixsrc. I didn't pursue it.
I hear it's a bit slow, but I wonder how much psyco
would help with that? :)
Dependencies
Wants the Twisted for networking
Wants pygame
pygame wanted an SDL_ttf library. Then had to reinstall
pygame to get SDL_ttf functionality included in pygame.
Installing font (SDL_ttf) support in pygame was
complicated by setup.py's lack of knowledge about x86_64
library directories on FC3. Editing Setup manually seems
to have gotten around it. (probably only on x86-64 bit systems)
Files had MS-DOS EOL convention; ran than through fromdos
Changed default port to 5901
Commented out protocol version check
export LD_LIBRARY_PATH=/usr/lib to make python find SDL_ttf
library (probably only on x86-64 bit systems)
It appears that pyvncviewer cannot be remote displayed over
an ssh tunnel. xterm worked fine though, in the same ssh
session.
Looks like the mouse functions, including scroll wheel are
working, however the enter key does not. :-s Backspace
does not work either. It looks like most of the unprintable
characters are not working, but most of the printable
characters are. An exception appears to be the arrow keys -
they seem to work. But, it looks like unprintable
characters are working in an mrxvt, but not in a
gnome-terminal... But then, when I was using an mrxvt,
pyvncviewer suddenly decided that I had sent an EOF or
something, because my mrxvt exited when it shouldn't have.
:(
Despite these problems, I think it might be workable...
It seems to be mostly gnome-terminal that's having trouble.
konsole, rxvt, mrxvt, and pterm seem mostly OK. In fact,
I've seen no glitches from konsole or pterm yet, and mrxvt
doesn't seem to glitch extremely often. But gnome-terminal
is unusable... In fact, looks like it may be gnome apps in
general, because gedit has much the same problem as
gnome-terminal.
I just saw an mrxvt get really confused under pyvncviewer.
It seemed to think that every key should be a control key.
pyvncviewer -might- be losing keystrokes sometimes too.
wind-networks -
the top hit on google of "palmos vnc", but the page is out of
date. It refers the interested reader on to the next link...
btinternet.com/~harakan/...:
this is where the top hit on google refers you. They have
something they call PalmVNC 1.40. It has 8 bit color, and does
not appear to be able to specify a port range other than that
starting at 5900. Also, when I try to connect to a RealVNC
4.0, built June 14, 2004, from this VNC client, I got "VNC
server supports protocol RFB 003.008. Viewer supports 3.3.
VNC versions incompatible."
palmvnc2.free.fr
has a version of PalmVNC that has been updated for PalmOS 5.x.
At the time I looked it over again, this site had "Latest stable
version: 2.0.5 build 214" and "2.0.6-dev build 225". 2.0.5
build 214 sounds like what I tried before, that was crashing my
T|C left and right - but no longe does. 2.0.6-dev build 225
seemed like a panacea for a while, but then it started causing
hard resets :(
I used to use 2.02, which was mostly stable, but
sometimes didn't get colors right. Also, sometimes it would
start refusing to accept keystrokes.
A definite downside of this application for Linux/UNIX users, for
example on my Tungsten C, is that there is no keyboard facility
for entering *ix characters like ~, {, \ and so on. However, it
turns out that you can define shortcuts for these special
characters, and those shortcuts should work in PalmVNC.
UltraVNC seems
to be all windows (do they, or do they not, have a PalmOS
client?)
The echo, export, micro and tridia versions of VNC all turned up
essentially nothing for Palm
First off, let's start with a script. It's
called run-vnc. It's the script I use from home, at NACS, and at
ESS, to get consistent sessions
If you examine it, you'll see
that sometimes I'm using zebedee (from home, because that's the
slowest link I use, so it benefits from zebedee's speedup.
It's set up to connect to two different servers that I use
commonly for VNC sessions
Usage:
ssh tunneling
Just use run-vnc --dcs to fire up a vncviewer that is
tunneled over ssh
zebedee tunneling
Perform once:
Fedora's vncclient.zbd is set up for windows. You'll
need to modify it for Fedora. :) If you're not on
Fedora, you may need to pull vncclient.zbd out of the
zebedee distribution.
I like to put vncserver.zbd in $HOME/lib/vncserver.zbd,
so it's available to run-vnc
Perform each time you connect via zebedee:
First, log into the server you want to connect to.
Then run run-vnc --server. You can actually skip this
step on subsequent connections, until the server is
rebooted.
Next, on the local machine, run run-vnc --dcs, to fire
up a viewer that is tunneled over zebedee
Patches
Here are patches
to make zebedee work on AIX 5.1. I've only tested the
server side, not the client side.
vnc-eye
sounds like a great teaching tool in a lab situation. It allows the
teacher to see all of the students' screens, and allows the teacher
to export their screen to an arbitrary list of students.
Tridia's offering isn't
looking very active, however, they still have some interesting things
on their website.
Their jVNC embeddable VNC server code still looks interesting
for VNC-ifying java programs. Imagine, for example:
A printer that shows the page its currently rendering
to the interested enduser, as the page is being rendered
prior to printing.
A device (like a palm) that doesn't have a complete
java implementation (OK, SuperWaba, but that doesn't
count), but does have a VNC client... The Palm
can then still make use of the java app in question.
They also have a nice enhancements
page, though the links are showing their age quite a bit.
Controlling a physical X display using VNC
x11vnc - It claims
to be more efficient than the one that comes with RealVNC
(x0vncserver), and purportedly works with any VNC client.
Another way of
controlling a physical display with VNC (two actually). This
one's called "xf4vnc". One of the implementations is a .so
that XFree86 can use... (Does this .so implementation
always run with the permissions of the X server?)
Vino is
a gnome-centric means of exporting a physical display over VNC.
Server Side Scaling (SSS). This allows a device with a
smaller display to quickly get an overview of what's on the larger
RFB display.
There is at least one vncserver implementation for windows
that does this.
Here's a
README for a patch that adds SSS to some unknown Xvnc source
tree. It did not apply well against TightVNC's Xvnc
sources. It may be intended for the RealVNC 3.x source
tree. It's also reported by its author to have some
glitches once compiled successfully.
"Somewhere out there", exists a RFB proxy that can
implement this functionality. I'm on the lookout for this
code... Here's a lead.
It might be possible to construct one without a great deal of
headache, using libvncserver.
Starting your vnc viewer with jpeg compression turned off
(often "-nojpeg") may be a good idea if you're using scaling.
Some vnc viewers may require the screen dimensions to be
multiples of 4.
x11vnc (CVS only?) is reported to have SSS.
FVNC supports
SSS on linux, however, it only supports certain encodings, only
certain bit depths, and it's distributed in the form of a patch
relative to an older version of RealVNC.
fbvnc
supports scaling in some form. It's a client for the
linux framebuffer device.
Apparently Hermann Seib has done some work on SSS for RealVNC
4.x, however it's not yet clear if this is windows-only code or
not yet.
The "Enterprise" version of RealVNC includes SSS, but I
imagine that's only available for a fee....
Mar 18, 2005: Verified that RealVNC 4.1.1 (Free Edition) does
not support PalmVNC-style SSS. 1:1 works fine, but 1:2 drops
the connection immediately.
Scripting VNC sessions: rfbplaymacro.
There's also some sort of interesting-sounding proxy
(rfbproxy)
associated with this project, that can be used to capture RFB
traffic in two formats, one of which can be fed back into
rfbplaymacro
ixvnc:
launching vnc from inetd (and probably xinetd too?) Downside:
All sessions apparently run as user "nobody". "Note that as of
3.3.3r2, Xvnc includes the functionality of iXvnc already.
However Andre's page is still the best documentation for how to
use it at the moment." (I assume this means RealVNC)
What exactly isvnc-reflector?
It appears to be some sort of VNC proxy server, but beyond
that... I'm really not sure. It might be intended to
implement RFB display sharing, however IINM, most modern VNC
clients include this functionality out of the box. Apparently
it can switch a bunch of VNC clients to a different VNC server,
en masse.
The
Sunray VNC Project is apparently a bridge between the Sunray
"SLIM" protocol and VNC. I don't see any file downloads
associated with this project yet, Sun Dec 5 20:23:57 PST 2004,
but it might be worth keeping tabs on.
NoMachine
NX is able to greatly accelerate X (and RFB and RDP too?).
You may want to check out my NX
notes. In short, I never got NX to accelerate RFB natively,
but X compression of a VNC viewer is very effective!
The files in aix-5-patches are patches to apply to your VNC
source tree, EG with "patch -p0 > gcc".
Then run the script called "local-script" (or just cut and paste
what you think you need. The pathnames may not be quite what you
expect, because I use these files with my cobble program to automate the build.
