Quick tip (learned the painful way): do not chain remote desktops, meaning don’t open a remote desktop (or VNC sessions for that matter) to one computer and open in that session a remote desktop to an other computer, unless you have bandwidth to waste and don’t mind the increased delay :-).

The explanation is rather simple (my head still hurts for banging against the wall for not figuring it out earlier :-)): remote desktop programs work by monitoring the screen and only sending areas which have changed. This has the advantage of reduced need for network bandwidth and less latency. However most window managers (and I’m not talking only about things like Gnome, but also the Windows GDI) provide notification only on a control level (a control is usually defined as a rectangular area which has its own window handle or equivalent – for example a button, an edit control, etc), because that’s the abstraction level they work on. Usually the flow of things in a GUI system goes like this:

• The GUI subsystem figures that a portion of the desktop needs redrawing
• It then creates a list of controls that need to do the redraw by intersecting the area occupied by the control with the area that needs to be redrawn, taking into account the spacial order of the controls (which is behind which).
• Finally it transmits a message to the controls which need to be redrawn with the exact area they need to draw

As you can see from the above list, the smallest unit the OS knows about (and thus the smallest unit it can notify other programs about) is a rectangular area of the control. Usually there is no way for the control to notify the OS that it has redrawn only a small portion of the rectangle. Now if we have an other remote desktop connection open, it basically acts as a big rectangle which continuously refreshes, and thus in turn must be retransmitted as a whole trough the primary connection. Basically you are getting a low framerate movie 🙂

Before anyone jumps at me: what I’ve said is true for bitmap based remote desktop products (that is, one which uses bitmaps rather than vector graphics to transmit the information). In case of vector graphics (like the X server of the NoMachine/NX technology) much of these concerns are eliminated.

So what is the solution? Probably you are remoting in through a third machine, because you can’t remote in directly. In this case it is recommended to port forward (through this third machine) to your machine the listening port of the remote desktop. Forwarding through something like an SSH tunnel also gives you added security over something like VNC which is essentially cleartext (or clear-image :-)) and truncates your password to 8 characters (that is from the point of view of a VNC server the passwords abcdefgh1234 and abcdefgh are equivalent). Of course SSH has its problems too, so be sure to only allow version two protocol (version one has some weaknesses) and use a strong password.

An other way to forward ports on Linux (to be used only on secured links!) is socat, which describes itself as netcat++. The most notable ability of it is that it can fork separate instances to handle multiple connections.

A related tip: if rdesktop keeps crashing on you, try to change your color depth. For example, it crashed when I was running 16 bit, while with 24 it works flawlessly, even though I was connecting using a 8 bit color depth.

Also note that your clipboard can stop to function when you have multiple remote desktop / VNC instances open. This is something I haven’t figured out a solution for and most probably is related to the way the different remote desktop products try to synchronize the clipboard.