Instructions relatives aux applications client/serveur
Les applications client/serveur ne doivent pas supposer qu’une connexion d’ordinateur unique équivaut à une session utilisateur unique. Il s’agit d’un cas particulier du problème abordé dans adresses IP et noms d’ordinateurs.
Pour identifier de manière unique une connexion client/serveur, chaque module client doit utiliser un nom ou un identificateur unique. Les applications peuvent utiliser des objets nommés ou des canaux, des sockets ou d’autres méthodes IPC. Pour plus d’informations, consultez espaces de noms d’objets noyau.
Pour être compatible avec les services Bureau à distance, le module serveur d’une application client/serveur doit être en mesure de gérer plusieurs clients se connectant à partir du même ordinateur. Pour ce faire, le module serveur doit accepter les connexions clientes via une interface globale bien définie, telle que RPC ou canaux nommés. Le serveur et le client doivent négocier un canal de communication différent pour chaque session utilisateur. Le client doit établir une connexion au serveur à l’aide de protocoles qui prennent facilement en charge ce type d’opération, tel que TCP/IP, où une connexion de socket différente peut être utilisée pour chaque application cliente.
Le module client peut appeler la fonction ProcessIdToSessionId pour récupérer l’identificateur de sa session services Bureau à distance. Le client utilise ensuite une forme de communication interprocesseur pour passer son identificateur de session au module serveur. Les modules client et serveur peuvent ensuite utiliser l’identificateur de session pour configurer un canal de communication privé. Par exemple, le module serveur peut utiliser un identificateur de session pour accéder aux objets de l’espace de noms de la session pour les objets noyau.
En outre, le module serveur peut utiliser l’identificateur de session dans un appel WTSQuerySessionInformation pour récupérer des informations supplémentaires sur le client. Le module serveur peut également utiliser l’identificateur de session dans un appel WTSSendMessage pour afficher un message sur le terminal client. Le module serveur peut également créer deux événements pour surveiller la connexion du client et la déconnexion d’une session. Toutefois, il doit être inscrit sur le serveur hôte de session Bureau à distance (hôte de session Bureau à distance) pour ce faire. Pour plus d’informations, consultez Surveillance des connexions de session et des déconnexions.
Les invites d’entrée utilisateur sont une source potentielle de problèmes pour les applications client/serveur. Par exemple, si un service appelle la fonctionMessageBox, la zone de message s’affiche sur le bureau du serveur hôte de session Bureau à distance, et non sur le bureau du client. Pour afficher un message sur un bureau client, le service peut appeler la fonction WtsSendMessage. Le service peut également demander une entrée à partir du module client, et le module client peut afficher l’interface utilisateur et renvoyer l’entrée résultante au service.
Les processus générés à partir de plusieurs sessions peuvent envoyer des données et recevoir des données entre elles via l’utilisation de blocs de mémoire partagée. Pour plus d’informations, consultez Création d’unde mémoire partagée nommée. La mémoire partagée ne peut pas être utilisée dans les conditions suivantes :
- Les processus utilisant le bloc de mémoire partagée ont été générés par plusieurs sessions.
- Les sessions partagent les mêmes informations d’identification d’authentification utilisateur.