Поделиться через


Поиск конечных точек

Серверные программы прослушивают конечные точки, чтобы принимать клиентские запросы. Синтаксис строки конечной точки зависит от используемой последовательности протокола. Например, конечная точка для TCP/IP является номером порта, а синтаксис конечной точки для именованных каналов является допустимым именем канала.

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

В этом разделе рассматриваются конечные точки и представлены сведения о том, как их найти. Она организована по следующим темам:

Заметка

Термины статических конечных точек и хорошо известных конечных точек эквивалентны, и используются взаимозаменяемо.

 

Клиентское приложение может использовать карту конечных точек, чтобы определить, запущена ли в настоящее время серверная программа. Клиент может вызывать RpcMgmtInqIfIds, RpcMgmtEpEltInqBeginи RpcMgmtEpEltInqDone, чтобы узнать, зарегистрирован ли сервер конкретный интерфейс, необходимый в карте конечных точек.

Использование известных конечных точек

Известные конечные точки — это предварительно назначенные конечные точки, которые программа сервера использует при каждом запуске. Так как сервер всегда прослушивает определенную конечную точку, клиент всегда пытается подключиться к нему. Известные конечные точки обычно назначаются центром, ответственным за транспортный протокол. Так как серверные компьютеры имеют ограниченное количество доступных конечных точек, разработчикам приложений настоятельно не рекомендуется использовать известные конечные точки. Еще одним преимуществом динамических конечных точек является упрощение долгосрочного управления и обслуживания системы.

Распределенное приложение может указать хорошо известную конечную точку в строке и передать ее в качестве параметра функции RpcServerUseProtseqEp. Альтернативно, строка конечной точки может быть указана в заголовке интерфейса IDL в качестве части атрибута интерфейса [конечной точки].

Для реализации известной конечной точки можно использовать два подхода:

  • Укажите всю информацию в строковой привязке
  • Хранение известной конечной точки в базе данных службы имен

Вы можете написать всю информацию, необходимую для установления привязки в распределенное приложение при его разработке. Клиент может указать хорошо известную конечную точку непосредственно в строке, вызвать RpcStringBindingCompose, чтобы создать строку, содержащую все сведения о привязке, и предоставить эту строку функции RpcBindingFromStringBinding для получения дескриптора. Клиент и сервер могут быть захардкожены для использования хорошо известной конечной точки или написаны таким образом, чтобы информация о конечной точке поступала из командной строки, файлов данных, файла конфигурации или IDL-файла.

Клиентское приложение также может запрашивать базу данных службы имен для получения сведений о известных конечных точках.

Использование динамических конечных точек

Число конечных точек для конкретного сервера и определенной последовательности протоколов обычно ограничено. Например, при использовании последовательности протоколов ncacn_ip_tcp, указывающей, что сетевое подключение RPC происходит с помощью TCP/IP, доступно только ограниченное количество портов (большинство систем имеют только диапазон 1025–5000). Библиотеки времени выполнения RPC позволяют динамически назначать конечные точки по мере необходимости. Так как количество возможных UUID интерфейса практически не ограничено, используя интерфейс UUID для направления вызова, предоставляет больше места для расширения и повышения гибкости.

По умолчанию функции библиотеки времени выполнения RPC ищут информацию о конечной точке, запрашивая базу данных службы имен. Если конечная точка динамическая, база данных службы имен не будет содержать сведения о конечной точке. Однако запрос даст клиентской программе имя сервера. Затем он может искать карту конечной точки сервера.

Если клиенту необходимо выполнить удалённый вызов процедуры с помощью динамической конечной точки, предпочтительный метод — сделать вызов на дескрипторе частично привязанной привязки. Время выполнения RPC автоматически определяет конечную точку. Этот метод превосходит использование функции RpcEpResolveBinding, поскольку он обеспечивает расширенные механизмы кэширования в среде выполнения RPC.

Если требуется более конкретный контроль над выбором конечной точки, клиенты могут выполнять поиск по одной записи в карте конечных точек за раз, вызывая функции RpcMgmtEpEltInqBegin, RpcMgmtEpEltInqNextи RpcMgmtEpEltInqDone.

Экспорт известных конечных точек в базу данных карты конечных точек

Можно смешать два подхода к поиску конечных точек, особенно при переходе распределенной системы из известной модели конечной точки в динамическую модель конечной точки. В таких переходах промежуточная версия сервера будет использовать хорошо известную конечную точку, но она также зарегистрирует известную конечную точку в базе данных карты конечных точек. Этот подход позволяет подключаться как клиентам, использующим хорошо известную конечную точку, так и клиентам, пользующимся динамической конечной точкой. После обновления всех серверов можно развернуть новую версию клиента, которая использует только динамические конечные точки. После обновления всех клиентов окончательная версия сервера может остановить использование известных конечных точек и начать использовать только динамические конечные точки.

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