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
| Share this post : |
|
|
|
|
|
|
|
|
EDITS:
- (CC – 10/13) – Hey Folks, I pulled the Calista information because it turns out we were working off some outdated information. Rather than keep it in there and cause confusion, we’ll come back after the Launch Series and do a deep-dive on Calista. Sorry for the confusion!
- (CC – 10/14) – One of our readers caught the fact that we still had the old architecture diagram in the post. In that diagram there was a reference to the DirectX10 commands being transmitted via VC. That feature was disabled for RTM based on feedback received during the engineering and validation process ( see the RDS Blog for details )