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

  • Статья

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

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

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

Примечание

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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