- 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!
- RealVNC. This is the one whose blood is blue.
- 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.
- VNC Camera Server
- 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.
- pyvncviewer -
written using python.
- 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
- mindvnc - encrypts. ssh v1 though. Also getting hard to find.
- http://sourceforge.net/projects/sshtools
- Epoch VNC appears to be a client for a variety of java-enabled cell phones, including Nokia's - not something for PalmOS
- jVNC
- vncj
- sshvnc
- J2ME VNC - apparently a java implementation of VNC that includes ssh v2.
- RealVNC FAQ
- TightVNC FAQ
- Ye Olde AT&T FAQ. There's a lot in it, but it's probably getting outdated.
- VNC Faq-O-matic
- Why
- By itself, VNC is an insecure protocol. People can see what you type and display, unless you tunnel through some sort of encryption system
- Although VNC takes pains to increase graphics throughput via a variety of compression algorithms, tunnelling can actually give even better performance
- ssh vs zebedee
- ssh is convenient in the sense that everybody has it already
- zebedee is a bit of a hassle, because it's something extra you have to install, on both the client and the server.
- Tunnelling VNC over zebedee gives quite better performance than tunnelling VNC over ssh, over a low bandwidth link. The zebedee authors claim that VNC+zebedee is faster than unadorned VNC as well, though I've never tried this due to security concerns.
- Windows users can get relatively convenient client-side zebedee+VNC using Dave Dyer's zvnc
- Setting them up
- 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.
- Perform once:
- ssh tunneling
- 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
- 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.
- A VNC Password Decryptor
- zebedee in java, along with what appears to be a zebedee-wrapped VNC client
- rfbcounter: a really simple VNC server. It suspect it actually just counts. :) Note: Not extremely flexible, as far as what RFB dialects it groks.
- vncmux - for running multiple VNC sessions off a VNC server, without having to worry about distinct port numbers?
- perlvnc - alpha quality, Dec 2004
- vncaudio: a linux kernel module that intercepts OSS and sends sound out over VNC.
- remotehost: a secure, VNC applet for Gnome.
- vnc2swf: Convert a VNC session to shockwave flash
- vnc2mpg - appears to depend on an older version of ffmpeg
- libvncserver
- 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.
- Their jVNC embeddable VNC server code still looks interesting
for VNC-ifying java programs. Imagine, for example:
- 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 is vnc-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.
- x2vnc - dual display for VNC
- 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!
- http://www.medialogic.it/projects/mlview/
- VNCRC: some rc scripts for vnc
- The old AT&T list of extras
- The Xvnc 4.0b4 that comes with RHEL 3 appears to be a lot faster than the Xvnc 3.3.3r2 that is available for AIX from the Bull AIX binaries website. Same for TightVNC 1.2.9 on AIX 5.1.
- TightVNC appears to be much simpler to build an Xvnc from than "real VNC", and claims to interoperate with other vnc implementations (AFAIK, it does).
- Xvnc 4.0b4 does not suport the GLX extension, not even slowly, which means you don't get much 3-D with VNC. Same for 4.0 proper and TightVNC 1.2.9 (server). I'm not sure about other Xvnc implementations. It's possible though, that if you recompile your GL apps against a non-DRI version of mesa, that you'll be able to do slow 3D.
- TightVNC 1.2.9 core dumps on AIX 5.1 when compiled with xlc as a 64 bit binary. It works fine when compiled with xlc as a 32 bit binary though.
- Although the Xvnc on RHEL 3 is blazing, it dies sometimes. The version that shipped with RHEL 3 is 4.0b4, same as on Fedora Core 2. I've put a copy of RealVNC 4.0 (the website didn't say anything about it being beta) in /usr/local/bin on dcs.nac, so I'm now using 4.0 proper on the server (dcs.nac), and continuing to use 4.0b4 on the client (particularly, from home). It's still screaming fast, but hopefully it'll be stable now too.
- TightVNC appears to support the "XTest" X server extension, making it suitable for use with something like xautomation. The RealVNC 4.0 I've been using does not support XTest, according to xdpyinfo.
- Tridia has a PDF describing the RFB (remote frame buffer) protocol. (link too generic)
- RealVNC's RFB protocol doc (PDF)
- A detailed description of how VNC works, from IEEE Internet Computing (on AT&T's website).
- An article I wrote about VNC, with regard to CPU vs Bandwidth tradeoffs
- I'll be using AIX 5.1 and TightVNC 1.2.9 as an example. It's probably relatively difficult to build on. If you're building on Linux, or possibly even Solaris, this is most likely much easier.
- First, download a copy of tightvnc-1.2.9_unixsrc.tar.bz2.
- Then download these files.
- Extract both archives
- 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.
- Finally, "make install" should wrap things up
- Here are some patches to tightvnc-1.3dev5_unixsrc.tar.gz that make the sources build on Fedora Core 3.
Hits: 13862
Timestamp: 2024-11-22 01:52:44 PST
Back to Dan's tech tidbits
You can e-mail the author with questions or comments:
