Contrairement à X11 ou Xfree86, qui est déjà architecturé en client/serveur, Terminal Server a nécessité des changements dans Windows NT : en effet à l’origine ce système se destinait à une utilisation en serveur de fichier ou d’imprimante. Il était alors mono-utilisateur et son interface graphique ne se destinait qu’a un seul utilisateur.
La société Citrix développe une version multi-user, c’est Winframe. En 1997, Microsoft signe un accord avec Citrix afin d’intégrer la technologie au noyau, sort alors Windows NT 4.0 Terminal Server Edition, la première version de Windows réellement multi-user développé par Microsoft. C’est ce noyau qui est intégré dans Windows 2000 et qui soutient les Terminal Services fournit avec Windows 2000 Server.
A la différence des terminaux X, Terminal Server ne stocke aucun état sur les clients, ceux-ci se contente d’envoyer les interruptions clavier/souris et de recevoir en retour les rafraîchissements d’écran. C’est donc le serveur qui effectue tous les calculs, puis il envoie les données sur le réseau. Le protocole RDP repose sur le protocole de conférence T.120 utilisé par Netmeeting, il permet en théorie de gérer 64k canaux simultanément.
Les modifications apportés se situent autant dans la partie noyau qu’utilisateur :
Les changements concernent essentiellement deux programmes : Win32 et Object Manager.
Win32 gère le GUI, c’est à dire normalement un clavier et une souris dont il redirige les interruptions vers l’application approprié. Elle répond ensuite par un appel à Win32 pour modifier son affichage. Pourtant Terminal Serber permet de gérer plusieurs clavier/souris ce qui serait impossible avec l’implémentation standard de NT.
De plus NT ne permet pas de lancer plusieurs instances de la même application car certains logiciels utilisent des objets nommés pour communiquer, or l’Object Manager utilise un espace de nommage global et les applications sont développés pour n’être utilisés que par une seule session.
Terminal Server est implémenté par Termserv.exe qui communique avec la partie user de la couche Win32 et la pile réseau RDP (cette pile contient notamment wdtshare.exe, responsable de la sécurité des sessions et du cryptage). Il utilise les librairies qui implémente le protocole T.120 : General Conferencing Control (GCC) et Multipoint Communications Services (MCS).
Lorsqu’un client se connecte, Termserv.exe appelle le Session Manager (smss.exe) qui crée un nouveau sous système Win32 en mode noyau (Win32k) ainsi qu’un nouveau Winlogon. Ensuite le Session Manager crée une nouvelle instance du Win32 Client Server Runtime Subsystem (csrss.exe). Ce process est associé à un SessionId unique qui servira au dialogue avec les applications.
Les nouveaux programmes sont associés à ce process qui cloisonne les différentes sessions car ils héritent tous de lui (c’est le processus user père de chaque session). Winlogon va se charger de lancer un shell (explorer.exe la plupart du temps). Il vérifie auparavant qu’une session déconnecté n’est pas en attente auquel cas, il notifie Termserv afin de transférer la connexion vers cette session. Ceci permet à un utilisateur de se reconnecter à la même session en gardant le même état sur différentes machines.
Cela peut s’avérer utile après le plantage d’un client : le travail n’est pas perdu, il suffit de se reconnecter. Une autre particularité de la reconnections est la possibilité de reprendre une session avec une résolution différente (passer du 1024*768 à du 640*480), le système redimensionne automatiquement le bureau. C’est très utile si les client n’ont pas la même résolution d’écran.
Architecture mémoire classique et Terminal Server :
L’architecture 32 bits de NT comprend une portion mémoire de 4Go divisé en 2 parties : 2Go utilisateur dans la partie basse et 2 Go pour NT Executive, Win32, HAL et le noyau. Cette partie haute est statique et ne permet pas d’utiliser un espace d’adressage multiple. Or chaque session utilise un win32k subsystem propre qui se trouve dans la partie haute de la mémoire.
Microsoft a donc étendue l’architecture mémoire de NT afin d’y inclure une portion au milieu des 2 Go noyau destiné au différentes sessions. Le Session Space occupe une taille fixe de 80 Mo au dessus de l’espace alloué au noyau et aux couches qui constituent NT Executive. C’est dans cette espace que s’instancie les Win32k. Le mécanisme adopté est le même que celui utilisé pour mapper la mémoire virtuelle dans l’espace utilisateur.
Nota : le scheduler n’a pas été modifié pour gérer les session multiples, ce qui signifie que le système ne se soucie pas de l’appartenance des threads lors des décisions prises par le scheduler.