- Dec 03, 2020 TigerVNC is an advanced VNC implementation, which includes features from TightVNC and TurboVNC (accelerated JPEG compression.). See the reference side-by-side comparison Compare free remote desktop software.
- X11vnc is an alternative VNC server which can also provide direct control of the current X session. X0vncserver does not currently support clipboard sharing between the client and the server. TigerVNC's vncviewer also has a simple GUI when run without any parameters.
- TigerVNC is a high-performance, platform-neutral implementation of VNC (Virtual Network Computing), a client/server application that allows users to launch and interact with graphical applications on remote machines. TigerVNC provides the levels of performance necessary to run 3D and video applications, and it attempts to maintain a common look.
Last updated: 18 Jun, 2020 Copy Copied Virtual Network Computing (VNC) software provides a way to reduce X11 overhead on high-latency networks such as the Internet. In practical terms, once a VNC session is underway, latencies are on the order of seconds rather than minutes. VNC can make remote X11 applications useful instead of being tedious and non-productive. The principle of operation involves a host server process (for example, Xvnc) that communicates with X11 applications running on Pleiades. The host server process transmits images and image updates using a low-overhead protocol to the remote system's viewer client. Security and FirewallsIn the NAS environment VNC traffic is carried by a tunnel, similar to the way is used to tunnel X11 traffic. Using an tunnel provides security because encrypts tunnel traffic in both directions. If you are already using , then VNC traffic will travel to/from NAS systems over current connections and through current firewalls. There is no need for any additional communication updates or authorizations. Where is the VNC Software?The Pleiades system runs on Linux. All of the necessary VNC software is installed in /usr/bin. You do not need to run an X11 server on the remote system (your local system) because in the VNC environment, all of the X11 work is done on the Pleiades front-end systems (pfe[20-27]). However, you do need a VNC client viewer. The client might already be installed in many Linux distributions and on recent versions of Mac OS X; if it is not installed on your system, you will need to download the client. If you have a NAS-supported system, please note that:
If you have a Windows desktop system, you can download free VNC clients from the following websites: Ask your local system administrator for help to install the VNC client software. Steps to Establish a VNC SessionIn the following steps, pfe24 is used as an example; you can substitute another PFE. Note: Although there are other ways to establish a VNC session, this method is convenient as it does not require you to manually find an available display number to use. Before You BeginVNC is much easier to use if you set up Passthrough on your local system. In your .ssh/config file on your local system, you do not need to enable X11 forwarding, but you must include the line ForwardAgent yes. Known Issue: Make sure you do not have a MATLAB, Tecplot, or FieldView module loaded when you invoke vncserver. Once the VNC session is established, you can load the module. Step 1: Connect to the PFEOnce Passthrough is set up properly, you can establish a connection from your local system to pfe24: Step 2: Run the vncserver Command on pfe24vncserver is a script that starts/stops/kills the actual VNC server, Xvnc. The first time you invoke vncserver on a server, you will be prompted to create a password for VNC that is up to 8 characters in length. (If you create a longer password, it will be truncated to 8 characters.) This password is encrypted and saved in the $HOME/.vnc/passwd file on the server. Once this is done, you will not be prompted for a password on the server when you invoke vncserver for subsequent VNC connections. Run vncserver as follows: There are a few options to the vncserver command, such as :display (for setting the display number), -geometry (for setting the desktop width and height in pixel), etc. The -localhost option shown in the above example is a local security option that you should use all the time. It must appear as the last option or it won't get processed. Similar to an X11 session, a VNC session uses a display number. If not supplied, the vncserver searches over the valid range from 0 to 99 and assigns the next free display number for your session. In the above example, a display number of 25 is assigned. Step 3: Create a Tunnel from Your Local System to the ServerThe next step is to create a tunnel from your local system to the server. This is done by first escaping into an sub-shell and specifying a local client's port number and a server's port number to use. The default escape characters are At the prompt, provide a local client port and a remote server port. VNC by default uses TCP port 5900+xx. Thus, it is common to provide the value 59xx for both the local client port (the number before localhost) and server port (the number after localhost). The value for xx is obtained from the final output from the vncserver startup command. In the example shown in Step 2, a vncserver was started on pfe24:25, so in this scenario xx would have a value of 25. The port number would therefore be 5925. Note that the client port number and the server port number do not need to be the same. Some may suggest using a very high client port number such as 22222 or 33333 since high port numbers are less likely to be reserved for other purposes. For example: The maximum number allowed for the client port is 65535. Avoid using the local port numbers 0-1024 (root privilege required), 5900 (for Mac systems, reserved for some Apple remote desktop products), and 6000-6063 (reserved for local X window server). Use the netstat -an command to check what local port numbers have been used: The above example shows local ports 5900 and 22 are in use and should be avoided. Step 4: Start the VNC Viewer Application on Your Local System
If everything goes well, the Xvnc server will send a X11 window manager display to your local system that will appear as an xterm in the viewer's window. The default window manager is TWM, and there are a couple other window managers to choose from in the /usr/bin directory, including FVWM, MWM, IceWM, and GNOME. The GNOME window manager provides a GUI view of a user's files and includes a few useful tools. To use a non-default manager, modify your $HOME/.vnc/xstartup file on the host where your start vncserver. For example: You can also change the size and position of the xterm in your viewer's desktop by changing the values in the following line of the $HOME/.vnc/xstartup file on the host where you start vncserver. For example: This specifies an xterm that is 80 characters wide, 24 characters high, at a position (10 pixels, 10 pixels) from the upper left corner of the VNC viewer's desktop. TIP: The modifications to the xstartup file only take effect for a new VNC connection. You will need to stop the existing VNC server and start a new one. The window manager's xterm is running on pfe24 itself. From this xterm, you can do tasks that you normally do on pfe24—for example, start an X application or to other NAS systems. PBS jobs can also connect to a VNC session. Specifically, in the xterm in the viewer's window, submit an interactive PBS job with the -X option (upper case 'X') and do not reset the DISPLAY variable before starting an X application: TIP: Your VNC session and the interactive PBS job will continue to be active even if you disconnect from the Pleiades front end where you started vncserver. Assuming the PFE where you started vncserver is not down, you can reconnect to the same VNC session: simply into the PFE (pfe24 in this example) and repeat steps 3 and 4 with the same port number that you used before (5925 in this example). If the interactive PBS session has not reached its wall time limit, the PBS job will be there waiting. Step 5: Shut Down the Server When You are Done with the VNC SessionOn each VNC server, there are a limited number of VNC sockets available. At the end of a session, be sure to exit the VNC application on your local system so that others can use the sockets. In the terminal window where you started up VNC, use the following command to clean up a few temporary files vncserver had created. For example: WARNING: Don't manually kill vncserver. Doing so will leave lock and socket files (for example, /tmp/.X11-unix/X25, $HOME/.vnc/pfe24:25.pid, etc.) on the server. TIP: If you get a black screen on your VNC viewer, try the following methods to resolve the issue:
|
Ssh + fail2ban + x11vnc win. You basically (and I'm noting the irony in using that work, knowing how complicated what I'm about to write sounds) run a SSH server.Use fail2ban to stop people brute forcing it. Put it on a non-standard port for bonus points. Then from Windows (Putty, a SSH client) you connect to Ubuntu forwarding the Ubuntu's local VNC traffic over the SSH connection to a.
Preface
Here you can see how new Tight-1.1 encoder operates as compared to older Hextile and Zlib encoders. Zlib encoder was obtained from the TridiaVNC source archive for Unix. Results for older version of the Tight encoder are also shown here ('Tight-1.0' column). The 'Tight-1.1L' abbreviation means Tight-1.1 encoder with new 'gradient' filter turned off (this can be done with -lazytight Xvnc command-line option). Main competitor is Zlib encoder, and that is why improvements in compression ratio for the Tight-1.1 encoder against Zlib are emphasized using red color for text.
In the bottom of this page you can find more information on testing and other related issues. Note that all test sessions as well as complete source code for testing utility are freely available for everybody. But you should be aware that some of test sessions are huge downloads and they may reside behind a very slow Internet connection.
The results
Test session 1: bugzilla-16.rfb (bzip2-compressed: 439,285 bytes) | Encodings | |||||
---|---|---|---|---|---|---|
Raw | Hextile | Zlib | Tight-1.0 | Tight-1.1L | Tight-1.1 | |
Data size in screen updates, bytes | 32,729,254 | 1,590,721 | 652,572 | 518,112 | 499,140 | 499,140 |
Bandwidth savings, Tight-1.1 vs. others | 98.47% | 68.62% | 23.51% | 3.66% | - | - |
Compression time, seconds | - | 1.3 | 25.8 | 18.9 | 14.8 | 14.9 |
Description: | This is 16-bit-color test session, presenting operations in Netscape Navigator window on KDE desktop. Browser is showing Bugzilla Web site. Original session is available from the rfbproxy Web pages. |
---|---|
Explanations: | Test shows good compression performance achieved by the Tight Encoder on typical session where not many full-color areas can be found on the screen. Most improvement in both compression ratio and compression time is caused by replacing true-color RGB samples with indexed colors before compression. Due to the problem found in the Tight-1.0 encoder, the compression ratio achieved by Tight-1.1 (where the problem has been fixed) is a little better than for version 1.0 of the encoder. Compression time has been decreased for Tight-1.1 vs. Tight-1.0 due to speed optimizations in 1.1 release. Results for Tight-1.1L and Tight-1.1 do not differ because the latter encoder has not found any areas suitable for preprocessing with the 'gradient' filter. |
More details: | Here you can find original test results for this session, where you can see compressed data sizes separately for each rectangle of screen updates: bugzilla-16-logs.tar.bz2 (download size: 144,024 bytes). |
Test session 2: compilation-16.rfb (bzip2-compressed: 252,800 bytes) | Encodings | |||||
---|---|---|---|---|---|---|
Raw | Hextile | Zlib | Tight-1.0 | Tight-1.1L | Tight-1.1 | |
Data size in screen updates, bytes | 111,178,662 | 2,788,259 | 1,836,495 | 476,738 | 454,748 | 454,748 |
Bandwidth savings, Tight-1.1 vs. others | 99.59% | 83.69% | 75.24% | 4.61% | - | - |
Compression time, seconds | - | 5.2 | 231.5 | 29.7 | 21.5 | 21.3 |
Description: | This 16-bit-color session shows Xvnc compilation process started in xterm window maximized to occupy almost full screen. The window manager is IceWM. |
---|---|
Explanations: | This test session is prepared in order to show Tight Encoder efficiency on compressing two-color (monochrome) screen areas. We see that compression ratio on such data may be four times (!) better than it stands for pure Zlib compression. Compression speed improvement is even more impressive: Tight encoder is about ten times faster on this session as compared to Zlib encoder. Also note raw data size: it's about 106 MBytes, and it's only 444 KBytes for Tight-1.1 encoding (compression ratio is 244.48). Such improvement in both compression ratio and speed is caused by replacing 16-bit true-color pixel values with 1-bit indices in 2-color palette. So the input stream size for final zlib compressor may be up to 16 times smaller. This allows zlib library to use its small (32K) dictionary much more efficiently. And compression speed is increased dramatically just because there is much less data to compress. |
More details: | Original test results for this session: compilation-16-logs.tar.bz2 (download size: 12,392 bytes). |
Test session 3: bars-16.rfb (bzip2-compressed: 4,746,651 bytes) | Encodings | |||||
---|---|---|---|---|---|---|
Raw | Hextile | Zlib | Tight-1.0 | Tight-1.1L | Tight-1.1 | |
Data size in screen updates, bytes | 32,880,890 | 11,812,296 | 3,632,612 | 3,852,823 | 3,482,707 | 3,191,666 |
Bandwidth savings, Tight-1.1 vs. others | 90.29% | 72.98% | 12.14% | 17.16% | 8.36% | - |
Compression time, seconds | - | 2.6 | 74.7 | 62.6 | 45.8 | 52.3 |
Description: | 16-bit test session demonstrating intensive use of full-color graphics. It's a WindowMaker desktop with wallpaper enabled. A photo image is opened in a Gimp window, then some manipulations are performed on that window. |
---|---|
Explanations: | This test basically shows two things: certain problems with Tight-1.0 encoder on full-color images and the efficiency of new 'gradient' filter on suitable image data. You can see that Tight-1.0 compression ratio was worse than Zlib results and that compression is improved in version 1.1 even when 'gradient' filtering is disabled. And enabling such filtering gives us about 8% of extra bandwidth savings while compression is a little slower. |
More details: | Original test results for this session: bars-16-logs.tar.bz2 (download size: 122,352 bytes). |
Test session 4: kde-hearts-16.rfb (bzip2-compressed: 3,130,374 bytes) | Encodings | |||||
---|---|---|---|---|---|---|
Raw | Hextile | Zlib | Tight-1.0 | Tight-1.1L | Tight-1.1 | |
Data size in screen updates, bytes | 22,901,336 | 13,711,535 | 2,011,507 | 2,381,792 | 1,787,521 | 1,788,952 |
Bandwidth savings, Tight-1.1 vs. others | 92.19% | 86.95% | 11.06% | 24.89% | -0.08% | - |
Compression time, seconds | - | 2.4 | 26.1 | 22.8 | 17.5 | 17.5 |
Description: | 16-bit test session demonstrating intensive use of full-color graphics used as background for icons and text. It is KDE desktop with wallpaper (coloured_hearts.jpg) enabled. Several kfm windows with different background images are opened, some simple manipulations are performed on these windows. |
---|---|
Explanations: | Again, this test shows Tight-1.0 problems and Tight-1.1 enhancements. Tight-1.0 results are poor as compared to Zlib encoder, Tight-1.1 results are much better. This session contains much data that is 'inconvenient' for the 'gradient' filter. And you can see that enabling this filter increases compressed data size a bit. But the difference is negligible because the code detecting still-image areas prevents such filtering in most doubtful cases. |
More details: | Original test results for this session: kde-hearts-16-logs.tar.bz2 (download size: 109,028 bytes). |
Test session 5: freshmeat-8.rfb (bzip2-compressed: 1,716,336 bytes) | Encodings | |||||
---|---|---|---|---|---|---|
Raw | Hextile | Zlib | Tight-1.0 | Tight-1.1L | Tight-1.1 | |
Data size in screen updates, bytes | 107,621,635 | 4,779,238 | 2,635,469 | 2,345,674 | 2,265,923 | 2,265,923 |
Bandwidth savings, Tight-1.1 vs. others | 97.89% | 52.59% | 14.02% | 3.40% | - | - |
Compression time, seconds | - | 7.4 | 147.5 | 98.0 | 86.6 | 86.2 |
Description: | This 8-bit-color (BGR233) session shows real dial-up session when a person is fetching his mail, reading news at freshmeat.net, searching there an utility he need, downloading it etc. |
---|---|
Explanations: | This session presents a bit of real computer usage. The color depth is 8 bits and the difference in compression ratios between Zlib and Tight is not very impressive. That is because at such color depth there is really not much space for improvement. However, note that the compression speed is still much higher as compared to Zlib and 14% decrease in data size is also not too bad. Looking at the compressed data size, keep in mind that this session is long enough: it's about 8 minutes of continuous activity. |
More details: | Original test results for this session: freshmeat-8-logs.tar.bz2 (download size: 785,370 bytes). |
Test session 6: slashdot-24.rfb (bzip2-compressed: 3,073,017 bytes) | Encodings | |||||
---|---|---|---|---|---|---|
Raw | Hextile | Zlib | Tight-1.0 | Tight-1.1L | Tight-1.1 | |
Data size in screen updates, bytes | 271,717,540 | 8,716,348 | 4,487,303 | 3,348,609 | 3,297,038 | 3,297,038 |
Bandwidth savings, Tight-1.1 vs. others | 98.79% | 62.17% | 26.53% | 1.54% | - | - |
Compression time, seconds | - | 5.7 | 341.8 | 149.4 | 134.2 | 134.2 |
Description: | 24-bit-color session showing a real dial-up session when a person is reading news at slashdot.org, generating a ChangeLog for CVS tree, editing it in XEmacs, fetching his mail and more. It's similar to the freshmeat-8 test session, but now color depth is 24 bits and there is more different types of activity seen on the screen. The session is about 6 minutes 30 seconds long. |
---|---|
Explanations: | The compression ratios are somewhat typical for real-world usage. The difference between Zlib and Tight efficiency is notable. Main reason is that many screen updates can be converted from true-color to indexed colors using palette with small number of colors. Another reason is that the tight compression is well-optimized for 24-bit sessions; it even converts 32-bit pixel values with one of bytes set to zero (as they are presented in RFB protocol) to 3-byte RGB samples. |
More details: | Original test results for this session: slashdot-24-logs.tar.bz2 (download size: 415,219 bytes). |
Test session 7: photos-24.rfb (bzip2-compressed: 8,187,724 bytes) | Encodings | |||||
---|---|---|---|---|---|---|
Raw | Hextile | Zlib | Tight-1.0 | Tight-1.1L | Tight-1.1 | |
Data size in screen updates, bytes | 25,569,676 | 16,781,057 | 10,657,746 | 9,830,852 | 9,966,649 | 6,130,479 |
Bandwidth savings, Tight-1.1 vs. others | 76.02% | 63.47% | 42.48% | 37.64% | 38.49% | - |
Compression time, seconds | - | 1.6 | 24.1 | 14.6 | 14.1 | 35.3 |
Description: | Test session demonstrating intensive use of full-color graphics in 24-bit mode. It is IceWM desktop with photo image used as wallpaper. Another photo is viewed in a Gimp window. |
---|---|
Explanations: | The results show great improvement (about 40%) in compression ratio when the 'gradient' filter is used on suitable data. When color depth is 24 bits, this filter can give greatest compression improvements. But you can see that the cost we pay for that is much slower compression. The second issue seen in results above is that the Tight-1.1L encoder operates a little worse than Tight-1.0 implementation. It's a rare situation, but it's possible. The reason is difference in algorithms used to split large screen areas into smaller sub-rectangles. The algorithm used in 1.1 version typically operates better, but that is not the point for all possible situations. |
More details: | Original test results for this session: photos-24-logs.tar.bz2 (download size: 32,044 bytes). |
Test session 8: kde-hearts-24.rfb (bzip2-compressed: 5,800,212 bytes) | Encodings | |||||
---|---|---|---|---|---|---|
Raw | Hextile | Zlib | Tight-1.0 | Tight-1.1L | Tight-1.1 | |
Data size in screen updates, bytes | 36,152,860 | 20,052,400 | 2,066,224 | 2,242,507 | 1,744,684 | 1,790,153 |
Bandwidth savings, Tight-1.1 vs. others | 95.05% | 91.07% | 13.36% | 20.17% | -2.61% | - |
Compression time, seconds | - | 2.4 | 46.0 | 27.2 | 20.4 | 20.6 |
Description: | 24-bit test session demonstrating intensive use of full-color graphics used as background for icons and text. The session is very similar to kde-hearts-16. It is the same KDE desktop with wallpaper enabled. Several kfm windows with different backgrounds are opened, some simple manipulations are performed on these windows. |
---|---|
Explanations: | The results are similar to those for the kde-hearts-16 session. It's clear that not every full-color image is a good candidate for the filtering algorithm implemented in the Tight-1.1 encoding even when color depth is 24 bits. Image type detection routine tries to prevent applying the filter when it thinks the data is not suitable for it, but this is not 100%-reliable, so we've got a little loss both is compression ratio and speed when the filtering is on. |
More details: | Original test results for this session: kde-hearts-24-logs.tar.bz2 (download size: 86,154 bytes). |
More information on testing
Test sessions
Test sessions were recorded with rfbproxy, a program which can sit between VNC server and client and is able to record all data received from the server into a local file. After a session is recorded, it can be played back for remote client with the same program. All tests were recorded under Linux using standard Xvnc 3.3.3r1 as VNC server. The only encoding scheme used in test sessions was 'hextile' encoding. So you don't have to run VNC software with support for tight encoding if you wish to look at test session contents.
![X11vnc X11vnc](/uploads/1/1/8/2/118218918/362053685.png)
Note that the Unix version of vncviewer cannot be forced to use 16-bit or 32-bit (24-bit) pixel formats; it uses your default screen format as reported by the X server. It means you won't be able to look at 16-bit test sessions on 32-bit display and vice versa. So make sure you have set appropriate color depth for your X Window System installation before viewing a session with the Unix vncviewer. 8-bit sessions can be played back regardless of color depth (if there are enough colors), but you must use -bgr233 vncviewer option to view such sessions.
X11vnc Vs Tigervnc X
The testing
The testing has been performed on a Pentium-II machine (350MHz CPU, 512K CPU cache) with 64M RAM under GNU/Linux operating system (kernel-2.2.10-ac9, glibc-2.0.7 - yes, it's not very up-to-date).
X11vnc Vs Tightvnc
First, saved test sessions were distilled using small fbs-dump.c utility. This utility removes control information from test sessions saved with rfbproxy, producing files containing only RFB messages received from the server (see RFB protocol specification). This makes message parsing much easier for testing utility.
Finally, specially written compare-encodings utility was used to produce comparison results. This utility reads hextile-encoded framebuffer updates from a file, decodes them, encodes each rectangle with a set of different encoders and dumps statistics to the standard output. Source files for encoders are included unmodified from the VNC distributions (not true for zlib, where I had to make a pair of changes to adapt it for the Xvnc-3.3.3r1, but these changes do not affect performance in any way). Note that compression speed is not reported by the testing utility. Timing results were obtained by running modified versions of the utility separately for each encoding. Be aware that the testing utility was not aimed to be comfortable at its usage. No help for options, no warranty, configuration via #define directives or via renaming source files, etc. It's probably for use by programmers only.
X11vnc Vs Tigervnc Mini
The last thing to say here: if you'll be lucky to record a session where the latest version of tight encoder shows poor performance as compared to pure zlib compression, please make that session available for me if possible. This will help me to make the encoder better and its users happier. :-)
Vnc Servers For Linux
Last modified: Fri Jan 12 04:32:09 KRAT 2001 Constantin Kaplinsky:e-mail. |