Remote Viewing-Not Just a Psychic Power

Most people today are used to having a nice, intuitive graphical
environment when they sit down to use a computer. Gone are the days of
using a DOS machine or being lucky enough to have a dial-up account at
300 baud on a UNIX mainframe. Today, most people expect to be able to point
and click their way to work nirvana, even when that work is being done
on some other machine over a network. In this article, I look at some
of the available options, what the relative costs and benefits are,
and hopefully by the end, you should have enough information to make a
choice as to what would be the best option for you.

Before I begin though, I probably should take a look at what
actually is involved in using a GUI on Linux. The overwhelming majority
of Linux users will be using the X11 Window System (typically
shortened to just X11). X11 has been around since 1987. Since then,
it has gone through several revisions, and it's currently at R7. Any
X11 installation you are likely to encounter will be some version
of X11R7. There have been attempts to replace it, including Wayland,
Berlin/Fresco and the Y Window System, but they are fairly rare out in
the wild, and you'll need to go out of your way to run into them.

X11 is built on a client-server model. In this model, the X11 server
is the part that actually draws on a physical screen. As such, it is
the part you end up running on your desktop in front of you. The
client portion in this model is the user-space program that has output
that needs to be seen by the end user.

Figure 1. The X11 Window System (from Wikipedia)

The client does this by sending requests to the X11 server. These are high
level and of the form "Draw a window", "Add text to the
window border", "Move the window to the right by x
pixels". Because of this, there
potentially can be a lot of communication if a lot is going on.

When most people experience X11, both parts of this model are running on
the desktop in front of them. But, this isn't the only option. There is
no reason for the client and server to be on the same machine, or even
on the same continent. Because everything is done by sending messages,
those messages easily can be sent over a network connection.

The first thought that should come to you is "Hey, I can open a window
on my friend's machine and display rude pictures there." Unfortunately,
the writers of the X11 specification have beaten you there and closed
that particular hole. By default, X11 servers are configured not to
accept connections from clients on the network. You have to
allow this explicitly. You can use two separate mechanisms to allow
external connections. The older one is called xhosts. With xhosts,
you tell the X11 server to accept connections from the servers that you
permit. The command looks like this:

xhost +111.222.333.444

The newer authentication mechanism is called xauth. In this method,
the X11 server creates a cookie that is required in order to connect to
the X11 server. If you want to connect to the X11 server from a remote
machine, you need to copy this cookie over to the remote
machine. An example of doing this, from the xauth man page is:

xauth extract - $DISPLAY | ssh otherhost xauth merge -

This command pulls out the cookie for the current X11 server and
"SSHes"
it over to the remote machine and merges it into the user's xauth file.

Once you have done this, how do client applications go ahead and connect
to your X11 server? All programs that run under X11 accept certain command-line options. One of these is -display. With this option, you can tell
your client program to which X11 server to connect and send its output.
The general form of this option is:

-display hostname:display#.screen#

The reason for all of the parts of this option is that a given machine could be
running more than one X11 server, and each server could be running more than one
display screen. The first server and screen is labeled as 0.0, so in most cases you
will use:

-display hostname:0.0

As an aside, you can do this on your desktop. If you open a terminal, you can run an
X11 client program with:

-display :0.0

and it will show up on your default desktop.

A consequence of this is that you need to have a connection to the
remote machine that will be running the client program. Most times,
this connection will be over an SSH connection between your local
machine and the remote machine. Luckily, SSH provides the ability to
tunnel X11 traffic over your SSH connection for you. This tunneling
happens "out-of-band", so to speak. You start a session by SSHing in to
your remote machine and using either the -X or
-Y options. The -X
option is the preferred method. It sets up a secure X11 socket on the
remote machine using xauth as the authentication system. Unfortunately,
some X11 servers have a hard time with this, so you can use
-Y. This
essentially turns off any authentication. It is equivalent to using
xhost +.

Once your SSH connection is established, a new X11 socket is created
on the remote machine, and the environment variable DISPLAY is set to
point to it. From here on, any X11 applications you start on
this remote machine will send their output to your X11 server on your
desktop. When you do this, you may notice something. In most cases,
it is unbelievably slow—even slower than slow if the machine you are
connecting to is any appreciable distance away. Due, in part, to this
issue, the SSH developers have included an extra option,
-C. This
turns on compression of the data traveling over the SSH connection. A
side effect is that the packets being sent containing the X11
protocol instructions get bunched together and sent as a single unit. This
makes much more efficient use of the bandwidth available, because you are
cutting down the amount of control data that also gets sent over the line.

As I mentioned above, both X11 and X11 over SSH are notoriously slow. In
some cases, it is nearly unusable. Luckily, there's another option
available, VNC. VNC also follows the client/server model, but it reverses
the location of the client and server from what you might be used to with
X11. With VNC, you run a server out on the remote machine and then use
a client on your desktop in front of you. You can run a VNC server in the
background, where it sits and acts like any other service. It also doesn't
use any of the standard X11 sockets, so it will not interfere with any
standard X11 desktop that also may be running on the remote machine.
Because
it runs as a service, it can continue to run, whether you are connected
to it or not. You can think of it as a GUI version of the old standby,
screen.

There also are client applications for all the major operating
systems, and they are much lighter weight than a full X11 server. So,
you can start up vncserver on the remote machine, connect to it from your
Windows box, start some long-running process, disconnect and go home, and then
check on its progress from your Linux box. This is a great improvement
over straight X11. Also, you will notice that in most cases, it is a bit
more responsive than X11 was. This is due to the amount of information
being sent back and forth between the client and server parts of VNC.

Joey Bernard has a background in both physics and computer science. This serves him well in his day job as a computational research consultant at the University of New Brunswick. He also teaches computational physics and parallel programming.

Even over long distance (I have used X over ssh from a Washington DC site to San Diego California. What counts is the infrastructure.

Ssh also compresses the X protocol. What can slow it down is the multiplexing of streams across a connection. Most X applications have multiple streams (dialog/menu/workspace,...) and depending on how it is written, each independant window gets a separate stream.

The problem with replacements is what they DON'T support. Most don't allow "cut&paste" from a window from one system, to a window on another system.

The other bottleneck is solvable - nearly all toolkits open multiple 3d windows (even scrollbars are composed of a minimum of 4 windows) and each handles the border/background/scrolling independantly. And this multiplies the I/O overhead.

The solution is (of course) more software on the server - I think it should have a "toolkit plugin" that handles most of the overhead, with only the final operation passed back to the application. The common functions (dialog, scrolling, icons,menus) should be handled by the plugin - eliminating the need to pass draw/redraw events/requests over the net. This would also simplify the various toolkits, and allow a more common display presentation.

Right now, the only thing used this way are the "window manager hints" which are handled locally (to the X server).

The X Window system as been around long before 1987. The number after the X is the protcol level. I remember getting color in X back in 1985. Also back in the late 80s there was "shared X" which allowed a user to create a window (the shared X application) and then could put other application windows into the shared X window and other users could view (and interact with their keyboards and mice (which might have 3 to 14 buttons) with the stuff in the "shared X". By the way X came about because of an attempt to adapt "W" (a windowing environment running on an OS called V) which is when it got its networking capability). There are lots of X related standard options (which GUI applications were supposed to handle) which the developers of Gnome and KDE do not honor and (they modified a few of the standard X options such as the geometry).

It is fast and works well in environments with a variety of Linux and windows machines as it is compatible with the stock windows remote desktop client and the Linux rdesktop client. Works great for those cases where you need to log into some conference room windows machine with limited privileges and pull a desktop from your Linux box (without installing any client software).

Ease of setup may vary. I never figured it out on gentoo, but it works pretty much out of the box on Debian.

I've tried VNC and tinyVNC from a machine at home connected to one at work using VPN over cable-modem, and it was really painful. I also tried SSH -C to Cygwin/X, and it was even worse. Really unusable.

NX wasn't exactly snappy under those conditions, but it was completely usable. I turned off encryption, since I was using VPN already.

Over a LAN, it's quite good. Not quite the same as local, but very good. You won't want to watch YouTube over it, or play games, but for most tasks, it's fast enough to use all day, even at very high resolutions. I'm using two 1920x1080 monitors, no problem. I develop software running Eclipse on the remote machine over NX (scrolling through text and so on), and there's no problem.

One more for NX. I've been using the X11 combo to access my SunOS boxes (via XDMCP), don't know really why those boxes had a UI, some years ago. Shifted over to VNC for some time. Finally settled with NX, and have been using it since.

NoMachine(nx) blows away any other remote desktop option for linux. X is klunky over slow connections, as is vnc. NX is fast fast fast and runs using ssh encryption by default. X has served its purpose but it's time to move on. Ubuntu will be abandoning X for wayland soon and most distros will most likely be soon to follow.