Virtual Network Computing
Virtual network computing (VNC), a remote access application from AT&T Laboratories Cambridge, is a great tool for remote desktop viewing and manipulation. Its core function is to allow the user to use the VNC client to connect to a host running the VNC server and remotely use the server's desktop. Keyboard and mouse updates are sent to the server, and snapshots of the server's desktop are compressed and sent back to the client via the VNC protocol. A few of VNC's most compelling features are: excellent platform portability, an open-source code base, conservative bandwidth usage and excellent pricing (free!).
For this review I have evaluated VNC primarily in three areas: stability, performance and portability. Below, I also compare VNC to X to illustrate the domain of usefulness for each. For this evaluation I used the following test scenarios:
<il>LAN: Connecting between a K6-2 400 (Linux) and PIII 560 (Linux, Win2k) via 100Mbps Ethernet
<il>Broadband: Connecting between a PIII 650 (Linux, Win2k) and K6-2 400 (Linux) via 768kbps DSL
<il>Modem: Connecting between a P133 (Linux, Win98) and a K6-2 400 (Linux) via 33.6kbps modem
I tested using all machines involved as both server and client under all operating systems installed. Under Linux my test applications were xterm, Netscape 4.7, KDE, StarOffice 5 and the GIMP. Under Windows my test applications were command.com (or cmd.exe when applicable), Internet Explorer 5.5, Microsoft Word 2000 and Adobe Photoshop. Both platforms used unmodified copies of the current versions of VNC, 3.3.3r2/3.3.3r9 (Linux/Windows), both available on the web site. The results were somewhat predictable.
Installing the VNC server on Linux is fairly simple; you can run it out of the build directory if need be. Configuration of the server is achieved by editing the vncserver Perl script to match your system configuration, editing VNC's xstartup script to match your preferred desktop configuration, and running vncpasswd to set a password on the VNC server (it will refuse to run without one, which given the nature of the application is a good thing to do) Note that if you are using the Linux system as a client you don't need to do any more in the way of installation than copying the vncviewer program into a convenient location on your path. There are a number of things you should configure before you start the server, most importantly a password, the startup script, and resolution and color depth. You should also ensure that the default desktop that VNC loads does not use a pixmap as its desktop, as this will degrade performance greatly.
Installing the Windows VNC server is similar to the setup procedure of its Linux counterpart; unzip the installation files, run the installer and you're done. As with the Linux version, if you only want to use the viewer, you can simply copy vncviewer.exe to a convenient location and not install the server. The user interface of the Windows server will be somewhat easier for most people to configure (configuration is available via an icon on the taskbar). The one important limitation that manifests itself on the Windows platform is that connecting to a Windows VNC server connects you to the existing desktop visible on the console, rather than a virtual desktop created for VNC. This is due to the inherently single-user nature of the Windows UI, and there is no simple way to fix this short of running a version of Windows like NT Terminal Server Edition. Overall, though, installing VNC on a Windows system should present little trouble.
My first test used my LAN configuration. Performance on this setup (Linux on a K6-2 to and from Linux and Win2k on a PIII via fast Ethernet at 1024x768 true color) was quite good when going both ways, whether connecting Linux to Linux or using Windows as the client or server (performance in all instances appeared to be identical). While there was a slight but noticeable lag in updating the screen, all of the test applications were quite usable (as one would hope, given the connection over Fast Ethernet). The xterm felt as fast as if it were local, StarOffice loaded and displayed documents flawlessly, Netscape ran reasonably well, and the GIMP was slow but usable. The Windows applications functioned similarly with one exception, as explained at the end of this review. All in all, LAN performance is more than acceptable.
My second test was on the broadband configuration. The parameters of this test (Linux on a K6-2 to and from Linux and Win2k on a PIII via 768k DSL at 1024x768 true color) are both common and, as detailed below, quite sufficient for most applications. The applications reflecting the most common usage patterns—StarOffice and MS Word—both run acceptably over the DSL. Both command-line environments (bash in xterm and cmd.exe) worked fine and the web browsers were reasonably usable. This greatly increases the usefulness of VNC, as many small (and not so small) businesses as well as a fair number of home users rely on DSL or a comparable link for connectivity. The applications that I found not to work acceptably were the GIMP and Photoshop. Both choked the connection while editing, which makes sense considering that a full-screen bitmap photo at 1024x768x24 is more than two megabytes, and editing a photo involves redrawing the screen repeatedly. Other than the photo editing issue, however, I found that VNC was quite usable over the DSL. For accessing most office productivity applications, VNC over broadband performs acceptably.
The third and last test configuration consisted of the aforementioned K6-2 connected to a Pentium 133 via 33.6kbps modem. Due to my experience with the DSL connection, I deemed 1024x768 at true color likely to be too bandwidth-intensive to work well at modem speeds. Because the Pentium machine was a laptop with an 800x600 screen, I opted to use 800x600 at 16-bit color as the screen mode of choice. Before I go into the details of this round of testing, let me give you the one word summary: slow. To preserve one's sanity, I would not recommend spending a lot of time running VNC via modem. That said, basic applications ran without real problems. StarOffice, Word and the two command lines all were usable to a reasonable extent. Anything beyond that involved a great deal of waiting. I attempted to run both Netscape and Internet Explorer and, though both ran, they loaded pages so slowly as to make early builds of Mozilla seem lightning fast in comparison. The bottom line is that, while VNC does function over a modem to a certain extent, I would not recommend using it as anything other than a last-resort backup for your normal means of access to the desired remote computer.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Secure Server Deployments in Hostile Territory, Part II
- Hacking a Safe with Bash
- KDE Reveals Plasma Mobile
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python