Introduction

Here are two projects that work together to remote control PCs. This software only works for XP and above, and is very stable. The server can handle multiple clients, and each client can handle multiple connections to the same or different servers.

The projects are a server and client pair. The server is RDS, Remote Desktop Server, and the client is RDV, Remote Desktop Viewer. The executables are packaged up with the source code, and there are projects for Visual Studio 2005 and 2008. I built a custom project out of the ZLIB library and compiled it as a Windows library with the /MT settings. Both 32 and 64 bit library files, in Release and Debug mode, are included. The ZLIB.H and ZCONF.H files are also included. For examples of single-threaded usage, see the CZLib class. For examples of multi-threaded usage, see the classes CDriveMultiThreadedCompression, CMultiThreadedCompression, and CZLib.

The system can be broken into four main components:

  1. Network layer
  2. Compression layer
  3. Graphics layer
  4. Input layer

The network layer, CTCPSocket, relies on SOCKET events as provided by the O/S, and it then forwards them onto the message pump of the window that is expecting those messages. It has operator overloading, using << and >>, for sending and receiving data. The data is described by its own class in CPacket, and each type of packet has a constructor. The socket class is derived from CAsyncSocket. This class relies on network events, as relayed through the message pump, to notify the program when something interesting happens. Of note, the send function is the TransmitPackets function. The TransmitPackets function transmits in-memory data or file data over a connected socket. The TransmitPackets function uses the Operating System cache manager to retrieve file data, locking memory for the minimum time required to transmit, and resulting in efficient, high-performance transmission.

The compression layer can be compartmentalized in two parts with two categories in each part. The outer part is the threading model. The compression can either be done in single or multiple threads. For each kind of threading, there are available the ZLIB compressor and my own homegrown arithmetic encoder compressor. Compression occurs in the data packet that represents the bitmap data. My compressor was based on the knowledge of Jean-Loup Gailley and Mark Nelson in their book "The Data Compression Book - Second Edition" ISBN 1-55851-434-1.

The graphics layer is another area that is multi-threaded. This portion of the code has undergone significant improvements since the last version of the code. The system is over twice as fast now with this reworking of this section of code. The main body of the code creates a thread for each rectangular region of the screen which will be polled for changes. When a thread detects a change in its area, it posts a notification back to the main thread. The main thread then sends this packet onto all the connected clients. Each thread has an activity timer. The less frequent a change occurs, the less frequent that area is checked. When a change does occur in an area, the activity timer is reset to the shortest pause.

The input layer is in the client code. The client captures the mouse and keyboard events and sends them to the server. The server uses the SendInput function to act out these events.

TODO

There are two areas of the code which still need attention. The first area is adding the capability to interact with terminal server sessions and capture those desktops. Currently, the code can't see those desktops. I am researching this problem diligently because it irritates me. The second area is to add support for the DFMirage mirror driver. This is the mirror driver that Tight VNC uses. I'm not reusing the VNC code, but I will learn how to instantiate a mirrored device context to help my code know better about screen updates.

History