Рекомендации по приложению клиента и сервера

Клиентские и серверные приложения не должны предполагать, что одно подключение к компьютеру эквивалентно одному сеансу пользователя. Это особый случай проблемы, рассмотренной в IP-адресах и именах компьютеров.

Чтобы однозначно определить подключение клиента или сервера, каждый клиентский модуль должен использовать уникальное имя или идентификатор. Приложения могут использовать именованные объекты или каналы, сокеты или другие методы IPC. Дополнительные сведения см. в разделе пространства имен объектов ядра.

Для совместимости служб удаленных рабочих столов модуль сервера в клиентском или серверном приложении должен иметь возможность обрабатывать несколько клиентов, подключающихся с одного компьютера. Для этого модуль сервера должен принимать клиентские подключения через хорошо определенный глобальный интерфейс, например RPC или именованные каналы. Сервер и клиент должны согласовывать разные каналы связи для каждого сеанса пользователя. Клиент должен установить подключение к серверу с помощью протоколов, которые легко поддерживают эту операцию, например TCP/IP, где для каждого клиентского приложения можно использовать другое подключение сокета.

Клиентский модуль может вызвать функцию ProcessIdToSessionId, чтобы получить идентификатор сеанса служб удаленных рабочих столов. Затем клиент использует некоторую форму взаимодействия между процессами для передачи идентификатора сеанса в серверный модуль. Затем клиентские и серверные модули могут использовать идентификатор сеанса для настройки частного канала коммуникации. Например, модуль сервера может использовать идентификатор сеанса для доступа к объектам в пространстве имен сеанса для объектов ядра.

Кроме того, модуль сервера может использовать идентификатор сеанса в вызове WTSQuerySessionInformation для получения дополнительных сведений о клиенте. Модуль сервера также может использовать идентификатор сеанса в вызове WTSSendMessage для отображения сообщения в клиентском терминале. Серверный модуль также может создать два события для мониторинга подключения клиента к сеансу и отключения от нее. Однако для этого необходимо зарегистрировать его на сервере сеансов удаленного рабочего стола (узел сеансов удаленных рабочих столов). Дополнительные сведения см. в подключениях к сеансам мониторинга и отключениях.

Запросы на ввод пользователей являются потенциальным источником проблем для клиентских и серверных приложений. Например, если служба вызывает функцию MessageBox, поле сообщения отображается на рабочем столе сервера узла сеансов удаленных рабочих столов, а не на клиентском рабочем столе. Чтобы отобразить сообщение на клиентском рабочем столе, служба может вызвать функцию WtsSendMessage. Кроме того, служба может запрашивать входные данные из клиентского модуля, а клиентский модуль может отображать пользовательский интерфейс и отправлять полученные входные данные обратно в службу.

Процессы, которые возникают из нескольких сеансов, могут отправлять данные друг другу и получать данные друг от друга с помощью общих блоков памяти. Дополнительные сведения см. в статье создание именованных именованныхпамяти. Общая память не может использоваться в следующих условиях:

• Процессы, использующие общий блок памяти, были вызваны несколькими сеансами.
• Сеансы используют те же учетные данные проверки подлинности пользователя.