WS2008: Remote Desktop Connection Architecture

Day Nineteen.  There are only eight more days to go till the big day.  The excitement is definitely building.  Today's topic for discussion - Remote Desktop Connection Architecture. 

The Remote Desktop Connection 6.1 client is comprised of the following four functional layers containing individual objects that interact through a common set of core components.  The function layers that make up RDC Architecture are:

• Shell Layer
• ActiveX Layer
• Core Layer
• Transport Layer

The following diagram illustrates the relationship between the components of the RDC client application - we will go over each of them briefly:

The shell layer uses the interfaces exposed by the ActiveX layer to provide the Remote Desktop Connection Client (MSTSC.EXE), a web based shell (TSWeb), the Remote Desktops MMC snap-in (TSMMC.MSC) and Remote Assistance (MSRA.EXE).

The ActiveX layer provides secure interfaces to enable the different types of shells in the Shell layer.  The ActiveX control that is used for Remote Desktop Web Access is now included with the Remote Desktop Connection application.  In order for the Terminal Services ActiveX control to run properly, you must ensure that the ActiveX control is enabled in Internet Explorer.  The Terminal Services ActiveX Client control is implemented in mstscax.dll in the RDC 6.x client using the following Class ID: 4eb89ff4-7f78-4a0f-8b8d-2bf02e94e4b2.

The Core layer is the main "engine" for the RDC client.  It provides all of the protocol-related functionality and has the following functional layers:

• Core API which hides the internal implementation of Core (e.g. threading model and objects) and provides a simple interface to the ActiveX layer
• Core User Interface which manages the parent display window of a session.  It manages the scrollbars and maintains a window that is a parent to the output window.  It also handles various dialogs - for example auto-reconnect.
• Core Finite State Machine (FSM).  A FSM (finite state machine) describes states and transitions along with inputs that affect the choice of transition from a particular state - leading to a new state.  The Core FSM implements the finite state machine that leads the client through various RDP protocol stages.  It is the primary driver of other components during the connect and disconnect phases.
• RDP Stack.  The RDP stack is organized as a chain of pluggable filters.  The data from the network enters the bottom filter and flows to the top.  Each filter can look at the data and decide whether or not any action is needed, for example compression or encryption.
• Transport Stack which manages the interaction of client core with transport plugins.  It drives the name resolution, re-targeting across transport plugins.
• Input Handling which is responsible for sending all user input (keyboard / mouse) to the server.  It also maintains the synchronization of the client and server keyboard state
• Graphics Handling which is responsible for decoding and drawing the graphics data sent by the server
• Core Plugins.  Generic plugins such as RemoteApp are instantiated and initialized by Core API.  They can receive notifications about various events in the client core (such as display updates and auto-reconnect starts etc).  Additionally, plugins also use services provided by Core API such as threading and virtual channels

The Transport Layer provides the connection functionality for the client.  A TCP-based transport and an RPC / HTTPS (proxy) based transport are provided in the RDC 6.x application.

And that brings us to the end of this post.  Tomorrow is Day Twenty, and we'll take a look at some RDC Enhancements.  Until next time ...

- CC Hameed

Share this post :