Partager via


Instructions relatives aux applications client/serveur

Les applications clientes/serveurs 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 ou des canaux nommés, des sockets ou d’autres méthodes IPC. Pour plus d’informations, consultez Espaces de noms d’objets de 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 qui se connectent à 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 des 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, comme 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 interprocess 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 du 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 et des déconnexions de session.

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 fonction MessageBox , la boîte 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 obtenue au service.

Les processus générés à partir de plusieurs sessions peuvent envoyer des données et recevoir des données les uns des autres via l’utilisation de blocs de mémoire partagés. Pour plus d’informations, consultez Création de 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.