Microsoft Windows Server 2008 Terminal Services

9. Terminal Server Internals

Posted by Benny Tritsch on September 11, 2008

[TS Internals] [Windows Architecture] [TS Architecture] [User-Mode Processes] [System Processes] [RDP]

9.5. Remote Desktop Protocol Internals

Read in this lesson...

1. RDP Architecture
2. RDP Capabilities

 

When Microsoft started developing RDP (remote desktop protocol) it was based on International Telecommunication Union (ITU) standards.In particular, RDP adopted the standards of the T.120 protocol family, especially on T.125 Multipoint Communication Service–Protocol Specification (MCS) and T.128 Application Sharing.

RDP Architecture

The RDP protocol allows communication with up to 64,000 simultaneous channels. The screen is transmitted as a smart combination of vector and raster graphic (bitmap) elements from the server to the client or terminal. The client transmits keyboard and mouse interactions to the server. The communication is extremely asymmetric; most data is transmitted from the server to the client.

RDP was originally designed to support different network topologies. In its current state, it can only be executed through TCP/IP networks and is internally divided into several layers. The reason for this, at the lowest level, is that the T.120 protocol family, on which RDP is based, was optimized in accordance with some rather complex specifications of the ISO model. These were mostly grade-of-service mechanisms. Because these cannot be mapped to the TCP/IP protocol, an X.224-compatible adaptation layer handled mapping the specified service primitive of the ISO layer to the service primitive of the TCP/IP protocol.

Basically, only four service primitives are needed, three of which are for connection administration: connection request, connection confirmation, and disconnection request. Connection and disconnection are initiated by the client. When the server ends the connection, the client is not specially notified. In this case, the client implementation needs to address the defined behavior through corresponding exception handling. The fourth service primitive handles data transmission.

The layer above this one provides multicast services. Multicast services allow both point-to-point and point-to-multipoint connections. This is the only way to implement functionality with several endpoints, for example, remote control.

A special security layer comprises all encryption and signature services. It keeps unauthorized users from monitoring the RDP connection and prevents the transmitted data stream from being modified. The RC4 algorithm by RSA Inc. is used for encryption. A signature that consists of a combination of the MD5 and SHA-1 algorithms prevents data manipulation. Additionally, the security layer manages the transmission of the user authentication and the relevant licenses.

The truly relevant layer handles the transmission of mouse and keyboard input and display output. This mechanism is relatively complex. It negotiates the operations used during connection, and it manages the caching information of some data, which reduces the network load significantly.

Over the course of its development, the RDP protocol was further adapted to Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Server 2008 and their applications. Many extensions of the protocol relate to this specific type of environment. The original program transmits data over the RDP protocol stack to the TCP/IP protocol stack. Through the layer model described earlier, the data is directed to a channel, encrypted, divided into predefined sections, adapted to the network protocol, addressed, and sent on its way. On the receiving end, this process occurs in reverse, making the data available to the target program. Licensing modalities are monitored here and encryption methods selected. Additional services manage the protocol-specific adjustments in user mode.

Conceptually, Windows Server 2008 Terminal Services is independent of the RDP protocol. The protocol is basically exchangeable; Terminal Services provides a flexible platform for multi-user mode. This platform allows other manufacturers to develop alternative protocols that use Terminal Services functions.

Due to its higher capacity, a kernel driver provides the remaining runtime environment to generate the RDP data stream. The kernel is subdivided into a section for the transport protocol (TCP/IP) and a section for the session-specific communication protocol (RDP). The latter is executed by the Termdd driver, which transfers mouse and keyboard input from the remote clients to the kernel.

RDP Capabilities

A terminal server does not know which type of client will contact it next. Therefore, all parameters that characterize the client and describe its functions need to be transmitted when connecting. A set of predefined capabilities is used for this purpose.

Knowledge of client capabilities allows a terminal server to respond flexibly to a client's requirements. The capabilities are divided into several groups:

• General abilities: Client platform and operating system used, protocol version, and data compression supported.

• Bitmaps: Desktop size, preferred color depth, supported color depths, and bitmap compression.

• Character commands: Support local character operations, for example text output or administration for overlaying and redrawing panels.

• Bitmap cache: Temporary or persistent caching of frequently used bitmaps on the client.

• Color table: Supports a palette for drawing pixels in bitmaps.

• Panel activation: Controls the active application window when viewed singly versus in the context of a complete desktop.

• Remote control: Supports remote administration, allowing a client to be controlled from a remote location.

• Cursor: Defines mouse-cursor color properties.

Some of these properties are vital to the performance of the RDP protocol and warrant a closer look.

Graphics Display under RDP

If you view a user interface or a dynamic Windows application on a remote client, it reminds you of a digital movie. The action might be a bit abstract, and the cutover as application windows change or start is very abrupt. Displaying a graphical user interface on a remote client mainly requires the transmission of huge amounts of data. If modified screen sections were always transferred as a complete set from server to client, the data would easily amount to between several hundred kilobytes to more than a megabyte. For this reason, starting or ending a full-screen application is particularly expensive in terms of the required network bandwidth.

Therefore, optimizing the RDP protocol and its handling of graphical elements has been given the utmost attention and effort. The most efficient compression algorithms and administration mechanisms have been used, supporting almost all graphics operations of both a Windows desktop and Windows-based applications. The intended result is to keep computational effort and required network bandwidth at the lowest possible level.

The RDP graphics driver receives the graphics commands from the applications through the graphics device interface (GDI or GDI+). The application generates GDI calls including the information where and what to draw. These GDI instructions are then being forwarded to the RDP driver. Nevertheless, GDI does not recognize that the graphics elements are not displayed on a local screen. The RDP driver transmits that data to a remote client. This is exactly when optimization must occur. Most graphics operations focus on producing raster images (bitmaps), drawing graphics primitives, and displaying text characters.

A bitmap is a rectangle consisting of pixels of different colors, thus creating a specific pattern. For instance, an application symbol (icon) is such a bitmap. The display of a static bitmap can be accelerated using compression when transmitting. Compression is possible at low color depth through a simple temporary encryption scheme that transmits only one color value if several pixels of the same color appear in a row. The rates of compression can also be influenced by the applications used and by the design of the graphical user interface. For example, using many colors and horizontal color transitions is very critical. This is why the decoration of the panels in a remote client session is much simpler than on the console. The total number of colors used, as defined under bitmap properties, is also very important in the selection of the compression algorithm and the resulting compression rate.

Color palettes can further optimize bitmap use. A table containing color values is created and transmitted to the client. If individual pixels in a bitmap need coloration, the position coordinates in the table are transmitted, not the color value. The amount of data is always smaller when the color depth is high but the number of simultaneously used colors is relatively low. Thus, an individual color value requires up to three bytes, whereas the color position in a table with a maximum of 256 entries needs only one byte.

Even more problematic are animated images, that is, animated bitmaps. They result in significantly higher transfer rates on the network, even if they are very small (e.g. animated or blinking mouse cursor). In this instance, we need another mechanism to limit the data volume which is referred to as caching.

How does a Windows system paint graphics primitives, for example, lines or rectangles that make up many elements of the graphical user interface? The easiest solution is to draw a line by transmitting each and every pixel. A much more efficient method is a command that defines the start and endpoint, thickness, and color of a line. The rest can be calculated by the output device. Naturally, this feature also uses much more complex commands, such as redrawing a window after it has been overlapped. Here, caching also plays a key role in temporarily storing data of all panel elements and contents.

Individual letters in character strings are managed by a special kind of bitmap, the glyph. In principle, the output of characters using glyphs is much easier than transmitting letter bitmaps. A command requests only the output of a glyph at a set screen position. However, the number of different fonts and font sizes of the current font sets is quite problematic, as is the initial transport of the glyphs to the client.

Caching

We already mentioned another mechanism to reduce the amount of data transmitted. It is called caching or temporary storage. In this process, the client reserves memory that houses frequently used image fragments that can be displayed again without any network transmission taking place. Some character operations do not work at all without caching due to technical reasons.

Caching functions are not realized solely through the client's main memory. If local hard drives exist, they can permit so-called persistent caching, in which the cached data is still available even after a client reboot. In principle, special network components can also store RDP data and thus provide a global caching space on a LAN segment.

RDP supports the following caches:

• Bitmap cache: Cache for different kinds of bitmaps. Size and number of these caches is determined upon connection.

• Font cache: Cache for glyphs (character bitmaps). The cache size must be sufficient for storing all characters of a defined character set.

• Desktop cache: Cache for a desktop screenshot. A character command stores or displays this special bitmap.

• Cursor cache: Cache for mouse cursors that need special handling. Special graphics algorithms ensure that the correct mouse cursor is displayed on the desktop without generating a lot of network traffic and overloading the local processor resources. Drag-and-drop operations with the mouse therefore do not require the transmission of new graphical elements, but only the transmission of the new coordinates.

• Text cache: Cache for frequently used character strings and the corresponding formatting information. Glyphs from the font cache are used to generate a complete character string.

Virtual Channels and Mirroring

An RDP client or application can use a virtual channel to transmit specific information. Virtual channels thus help add functions that are not yet specified in the RDP protocol. They represent a platform that future developments can be based on without having to modify the communication methods between a terminal server and its clients. With Windows Server 2008 and RDP 6.x, virtual channels are used for features such as joint client and server clipboards and for redirecting print jobs to local client printers.

Basically, the RDP protocol allows distribution of data streams from one source to many destinations without having to send the data separately. An application can therefore be mirrored on or shadowed to another client. Even the point of input can be transferred from one user to another.

 

 

Read in this chapter...
9	Terminal Server Internals
9.1	The Windows System Architecture
9.2	Terminal Services Architecture
9.3	Processes in User-Mode
9.4	The Priviledged System Components
9.5	Remote Desktop Protocol Internals