You're probably familiar with Virtual Network Computing (or VNC) as a "productivity tool"; maybe you use it yourself. But you might not realize the exciting opportunities VNC presents as a development component.
Distinguished record of service
First, let's review VNC technology, which developerWorks has explored several times before. Most readers are familiar with VNC's basic operation: put a VNC server on a central machine, then VNC clients hosted remotely can view the central machine's graphical display. Now, that description sounds a bit like the X11 windowing system with some of the labels changed. As with X, VNC traffic can be encrypted, tunneled, wrapped, and so on. As with X, VNC helps exploit "compute servers" that can be centrally maintained while graphical results are visible "where users live."
Unlike X, however, VNC "multiplexes": your graphical applications continue to run unaffected even without a client desktop watching them, or even if several clients are watching simultaneously. VNC is also admirably portable; good implementations are freely available for a staggering range of hardware and operating systems, including mainframes, telephone handsets, and a surprising number of decades-old machines.
These features make VNC a solution for several development challenges. Suppose you have a graphical application running on a Linux box, and you've been instructed to port it to a Windows desktop or make it into a Web application. A nearly instantaneous answer is to feed the application display into a VNC server on the Linux host and rely on Windows- or Web-hosted VNC clients to view the application remotely. That achieves in an afternoon what might otherwise take weeks to port at the level of source code.
It gets better, though: VNC is also programmable. Practically programmable, that is, in a way other remote-control technologies such as X never were. So far, we've seen that power users can exploit VNC to partition computation and display across different machines, and developers can use the same technique to bring graphical results to end users. Now let's increase the granularity once more.
Not only can your end-users rely on battle-hardened, no-charge, stand-alone VNC viewers, you can also program your own viewer. You might, for example, make a VNC display be just one frame in a larger application. Or, you can tune the color palette and transparency of the VNC display and overlay parts of it with local graphics. Or, you can "vivify" the display, reverse information flow, and use pointer actions -- mouse clicks, drags, and so on -- to allow the end-user greater control of what he or she sees. You can continue to rely on mature VNC servers, perhaps letting introductory users experience the baseline functionality of a standard VNC viewer while you decorate your custom VNC viewer as your customers need.
Alternatively, you can move to the other end of the protocol. That is, rely on the popularity and familiarity of installed VNC clients, but feed them from a customized VNC server. We'll see below why this is likely to pay off even quicker for typical development efforts.
If you're new to VNC capabilities, find the link to "Getting Started with VNC" in the Resources section below. Most Linux distributions include basic VNC clients and servers, so it should take only a little study and practice for you to try out the ideas in this article.
X, Tarantella, and other technologies promised much the same opportunities for remote operation that VNC gives. They never made programmability easy, though. In place of their complexity, you can have your own VNC viewer or server in just a few hundred lines of source code.
tclRFB makes all this practical. tclRFB was created by Mac Cody, a principal physics engineer for Raytheon. In regard to tclRFB, he says, "My intent is to allow for the creation of lightweight, scripted remote interfaces, much like Proxy Tk."
RFB is the "Remote Frame Buffer" protocol on which VNC display communication rests. VNC and its RFB-reliant accessories have been written before in several languages, including C and Java. These programs and libraries were always rather difficult, though; they did little to encourage source-level reuse. Cody implemented RFB and scripted application programming interfaces (APIs) for it in the high-level Tcl language.
tclRFB simplifies RFB access dramatically, bringing it well within the reach of even casual programming. We'll see below how few lines of code it takes to create a VNC server or client with tclRFB.
Moreover, Tcl's polished graphics library means that tclRFB-based applications operate with all the performance (and sometimes more!) of conventional VNC clients and servers. Cody made a point of coding tclRFB in so-called "pure Tcl," so you need little more than a standard Tcl distribution to use his work.
The body of this article gives recipes for running demonstration tclRFB clients and servers that can be used with any standard VNC program. It concludes with some generalizations likely to help with your own development work.
It takes only a little time to try tclRFB out for yourself. Make sure you have Tcl/Tk 8.4 or higher installed; although tclRFB doesn't use the latest features of Tcl in a crucial way, it would be tedious enough to remove all the conveniences 8.4 affords that no one has yet done it.
Most Tcl distributions do require one extra module to work with tclRFB. This is because RFB depends on Data Encryption Standard (DES} encoding, and US export restrictions effectively prevent Tcl from bundling DES.
To get started with tclRFB, therefore, download the tclRFB and TclDES distributions (you'll find links for these packages in the Resources section at the end of this article), and unpack them, perhaps in $WORKING:
Listing 1. Unpack the modules necessary for tclRFB development
cd $WORKING
gunzip -d tclDES-0.5.tar.gz
tar xvf tclDES-0.5.tar
gunzip -d tclRFB-0.5.tar.gz
tar xvf tclRFB-0.5.tar
|
If tclRFB were an end-user application, it would be most convenient, for customers, to distribute it as a single-file executable. Tcl certainly provides facilities for this sort of "wrapping." As tclRFB is a development library, however, whose client and server programs are just models to teach its capabilities, it is handiest to keep the tclDES and tclRFB parts distinct and "unpacked." Export restrictions only reinforce this decision in favor of transparency and flexibility.
To see tclRFB in action, first set up a conventional VNC session. Start a server on a convenient host and verify its accessibility with a conventional VNC client; the Resources section will help you with this, if you're not already familiar with VNC operation.
With the server running, set Tcl's library search paths and launch the tclRFB-based client with this simple sequence:
Listing 2. Launch the demonstration tclRFB client
#!/usr/bin/wish
TCLLIBPATH="./tclRFB-0.5 ./tclDES-0.5/"
export TCLLIBPATH
tclsh tclRFB-0.5/examples/client.tcl
|
After configuring the session with network address, password, and so on, you should see the familiar VNC screen pop up -- but as a Tcl/Tk application!
client.tcl is barely five hundred lines of straightforward code. Working with it is easy enough that Jeffrey Hobbs, senior developer of Activestate Tools, adopted it -- along with the open source Snack audio program (see Resources) -- to build prototype pure-Tcl Webcast software in less than a day.
Most of client.tcl's code is conventional setup and decoration: dialogues and displays to configure the VNC session. The "active," VNC-specific, part consists of realizations of the RFB protocol in terms of Tk's high-performance "photo images." Here's an example:
Listing 3. ProcessColorRectangle implementation
proc ProcessColorRectangleRGB888 {pixel x y w h} {
set pixel [string range $pixel 2 end]
screen put #$pixel -to $x $y [expr {$x + $w}] [expr {$y + $h}]
return 1
}
|
This example updates a rectangular portion of the VNC display with a specified color. The rest of the client source is equally readable.
On the server side, tclRFB returns even more
A tclRFB-based VNC server can be even more compact. The rfbcounter.tcl example supplied as part of the tclRFB distribution is less than three hundred lines long.
This is practical, because a server doesn't have to do general-purpose graphics rendering itself! Clever coding synthesizes RFB messages that a client pulls together into an image. The server need only calculate patterns of data in memory. In this particular case, Cody defines a simple seven-segment "LED-style" display element. With just a few lines more of source code, Richard Suchenwirth of Siemens Dematic Postal Automation has shown with his strimj package how to achieve far more sophisticated results.
A working demonstration makes this more apparent. Start with a current Tcl 8.4; this saves the few megabytes added by a full Tcl/Tk installation.
If it's more convenient, of course, you can choose to use wish on the server side, too, for wish is a proper superset of tclsh. Unpack tclRFB, as before. Read the accompanying sidebar to set the session password. Launch your VNC server with the following:
Listing 4. Launch the demonstration tclRFB server
#!/usr/bin/tclsh
TCLLIBPATH="./tclRFB-0.5 ./tclDES-0.5/"
export TCLLIBPATH
tclsh tclRFB-0.5/examples/rfbcounter.tcl -clock 1
|
Now point any VNC client to display 1 on the host running rfbcounter.tcl. You'll see a display like that of Figure 1, a simple digital clock.
Figure 1. Display of VNC-transported simple digital clock
Do you see the possibilities this model opens? Suppose you want to monitor an operation on a remote host. We typically do this either by writing a Web application or by developing a custom client-server pair. One of the well-known limitations of Web applications, of course, is their clumsiness at updates -- essentially the whole client window must refresh. Customized client-server development is fraught with all the problems not only of shaking down a novel communications protocol, but also of deploying the clients to all the desktops or other hosts where they need to be seen.
With tclRFB in hand, though, you can write a tiny, application-specific server -- certainly smaller than any dynamic Web server you're likely to use. Host the server on any platform with enough computing power to handle a TCP/IP stack and the little more Tcl requires; that might be a PocketPC, an OS/400 minicomputer, or a processor embedded in a printer, networking device, or other physical equipment. Remember: as with Web servers, the tclRFB-based server just manipulates textual and arithmetic data and needs no direct knowledge of graphic displays.
In one way, this sounds like the Simplified Network Management Protocol (SNMP) model for network management of "agents" -- but with the advantage that the monitor displays are already installed on any screen with access to standard VNC clients. There's no need to deploy expensive "management consoles."
There are several other ways to combine the same elements. As Cody said, "Using tclRFB in conjunction with the Img extension allows for the creation of a backend for a Tcl/Tk application that can dynamically 'screen scrape' the GUI and deliver it to a remote user who can then interact with it. Remote delivery of the entire desktop would be unnecessary."
Yet another variety of "scraping" that tclRFB makes practical is to turn legacy "green screen" applications into graphics servers. Suppose you want end-users to monitor information from a legacy, "non-graphical" platform. Web applications are ill-suited to this sort of "push." You can readily drive it with a tclRFB server, though, and avoid deployment difficulties through reliance on standard VNC clients. As a bonus, simple strimj coding gives the ability to augment displays with arbitrary Unicode or other special-purpose graphics, with no need to install extra fonts on client desktops. Clients see fancy displays of the sort they'd never associate with tiny or old thin servers.
Figure 2. Good-looking icons achieved as strimj-coded "ASCII art"
The principle behind all these possibilities is to exploit a standard protocol and standard components with a well-written library that multiplies developers' effectiveness. What variations on the VNC theme would you like to play?
- The AT&T VNC home page offers background information and downloads (under the GNU GPL). Note particularly the explicit comparison to the technical alternative X affords of $DISPLAY redirection.
- If you've never launched VNC before, AT&T's tutorial Getting Started with VNC is probably the best place to start learning how to put it to use in your own work.
- "VNC works miracles for system administrators" is an introductory article Cameron wrote five years ago, soon after VNC's first public release.
- "The VNC protocol" page describes RFB.
- TclRFB and TclDES can both be found on SourceForge.
- "DES Encryption" introduces this standard cryptographic algorithm.
- The developerWorks series "Sharing computers on a Linux (or heterogeneous) network" describes use of ssh (secure shell) and VNC (Virtual Network Computing). Part 1 (developerWorks, December 2001) discusses what these technologies are good for as well as some setup issues. Part 2 (developerWorks, March 2002) covers more on VNC, then tackles the X Window System and security.
- This IBM Redbook tip covers the installation of SuSE 8.0 Linux and using VNC for remote administration.
- Cameron's personal notes on the X Window System points to introductions to Linux's underlying graphical toolkit.
- Tarantella is an ambitious product that consolidates application displays and makes them available as Web pages.
- "Proxy Tk: A Java applet user interface toolkit for Tcl" is a conference paper that describes this interesting proprietary development tool that simplifies realization of sophisticated visual effects within Web applications (in PDF).
- Cameron explains some of Tcl's features and advantages in "Expect exceeds expectations" (developerWorks, April 2002).
- The Snack Sound Toolkit is a cross-platform library for scripting audio operations.
- In "Economy of Means," Cameron touches on the elegance of the strimj package.
- Cameron's personal notes on SNMP (Simple Network Management Protocol) gives references to SNMP introductions, standards, and discussions.
- Img is an extension to standard Tk that gives it the ability to work with such image formats as PDF, XBM, and TIFF.
- The Tcl Developer Xchange is recognized as the standard Web home for the Tcl programming language.
- Find more resources for Linux developers in the developerWorks Linux zone.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
