Thoughts from the EPS Windows Server Performance Team
Welcome back to our Launch Series. Today is Day Thirteen – only a few more days to go! Today we’re continuing on with Remote Desktop Services with a look at the architecture. Here we go:
There have been some design changes in RDS (remote desktop services) and in RDC (remote desktop client). Let’s start by discussing the legacy RDP. RDP is a layered binary-encoded protocol that runs on a lossless connection-oriented transport. Some of RDP’s layers originated in code derived from the NetMeeting project, which in turn had roots in ITU standards (such as T.120). As RDP has evolved, the layers have diverged significantly from those standards for performance reasons as headers have been collapsed down and bit-packed for efficiency. Many of the core design choices in RDP have been made to optimize for performance – bandwidth on the wire as well as encode/decode speed. Many key-protocol structures are hand-designed to explicitly use the least amount of space possible.
The RDP protocol streams graphics in a server-push model with lazy updates to increase the opportunity for the server to coalesce multiple updates into one output packet. The RDP protocol is driven at the server by a scheduler that takes into account factors like user-input activity (mouse/keyboard) and can accelerate graphics output to provide a smoother interactive experience. RDP bandwidth use is variable depending on the scenario and design choices are made to ensure that it is ’quiet’ on the wire (no keep-alives or other packets are sent when the screen is not updating). Below is the legacy RDP Architecture:
The transport is abstracted behind a pluggable interface and Microsoft currently deploys RDP over TCP, TS Gateway (an RDP over HTTPS mechanism) and a Windows Live Tunnel (a GoToMyPC-like service using RDP). In Windows 7 the predominant security layer in RDP is a standards-based SSL/Front Authentication layer. This leverages the OS’s CredSSP library to implement a negotiation between Kerberos/NTLM and runs over the SSL encryption protocol. A variety of encryption algorithms are supported within SSL such as RC4, DES, and AES FIPS.
The RDP protocol stream consists of a set of virtual channels (VC’s) that are multiplexed by RDP into one protocol connection. VC’s are an extensibility mechanism used both internally to add new features to RDP as well as exposed to 3rd parties to allow them to add-value to RDP. For example 3rd parties can add device redirection features to RDP for customized hardware such as point-of-sale devices. A Virtual Channel is made up of a client plug-in, a server component that communicates with the virtual channel through TS API’s and the protocol stream the VC emits. RDP provides common services to virtual channels such as compression, security, multiplexing and virtual channel flow/prioritization.
The bulk compression layer implements a variety of history-based compressors using Lempel-Ziv (LZ-like schemes). These compressors operate on virtual-channel streams without specific knowledge of the structure of the VC protocols themselves. Bulk compression is found to reduce the overall RDP bandwidth from 30-80% depending on the scenarios.
We didn’t really go into the update types supported by the graphics source or the RDP client – we’ll come back to those in a later post after the Launch Series. For now, that’s it. I’m back tomorrow with a look at RemoteApp. Take Care!
- Dane Smart
Great summary. Are the Calista pieces in Server 2008R2? Will the CAC (Calista Codec) be documented on MSDN in the near term? Thank you!
In your diagram you indicate the DirectX 10 commands are transmitted via a Virtual Channel to be rendered on the client. However, according to a post on RDS Team Blog, this feature has been disabled in the RTM version of Windows 7 and Windows Server 2008 R2:
According to that post DirectX 10 output is transmitted as bitmaps.
You may have noticed that we pulled the Calista information from the post since we were working off outdated information. My apologies for the confusion