Справочник по утилитам. gns

Описание:

Менеджер глобальных служб имен (gns) является автономным менеджером ресурсов. С помощью утилиты gns приложение может выполнять объявление, поиск и использование (подключение) служб в сети при отсутствии информации о местоположении службы и ее поставщике.

GNS работает в двух различных режимах: сервер и клиент. Менеджер в режиме сервера представляет собой централизованную базу данных, в которой хранятся объявленные службы, а также обрабатываются запросы на поиск и подключение. Менеджер в режиме клиента выполняет передачу запросов на объявление, поиск и подключение между локальным приложением и сервером gns.

Интерфейсы API и правила объявления

Для использования в руководстве по библиотекам Neutrino Library Reference доступно несколько функций: name_attach() для объявления, name_open() для подключения, name_close() для отключения от конкретной службы и name_detach() для удаления имени из пространства имен.

Объявление (привязка) службы (представленной путевым именем) со стороны приложения может быть локальным или глобальным. При локальном объявлении службы поиск этой службы приложениями с другого компьютера посредством утилиты gns невозможен. При глобальном объявлении служб доступ к ним будет открыт для любого компьютера в сети, на котором запущен менеджер gns.

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

Объявление службы в приложении может быть глобальным только при наличии полномочий root.

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

Примечание. В реализации GNS использован API name_*, однако поведение относительно предыдущей реализации операционной системы реального времени Neutrino несколько изменилось.

Пространство путевых имен

Служба представлена пространством путевых имен (без первого символа "/") в каталоге /dev/name/global или /dev/name/local в зависимости от способа ее объявления.

Представление пространства имен /dev/name/global идентично для каждого компьютера, на котором запущен клиент или сервер gns. Помимо этого для каждого компьютера определено специфичное локальное пространство имен /dev/name/local.

Для получения дополнительной информации см. раздел "Примеры".

Правила подключения для GNS

Для подключения приложений к глобальной службе имен используется API name_open(). Если одна служба зарегистрирована на нескольких хостах, то для выбора конкретного экземпляра службы, к которой осуществляется подключение, применяются следующие правила:

Работа с несколькими серверами GNS

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

Работа с несколькими доменами служб

Можно установить несколько клиентов для подключения к серверу server1 и несколько клиентов для подключения к серверу server2. При этом создаются отдельные "домены служб". Клиенты, подключенные к серверу server1 (в "домене служб 1") не могут использовать службы, зарегистрированные на сервере server2 (в "домене служб 2").

На некоторых клиентах:

Резервные серверы GNS

Поскольку сервер GNS является централизованной базой данных, отсутствие резервных серверов GNS означает прерывание работы службы (объявление, поиск и использование) в сети. Для устранения этой проблемы можно запустить несколько серверов GNS и направить клиенты на все эти серверы.

На сервере 1:

В этом случае при каждой попытке регистрации глобальной службы приложением сообщение о регистрации отправляется одновременно на сервер server1 и server2. При каждой попытке подключения приложением глобальной службы запрос направляется одновременно на сервер server1 и server2.

Примечание. GNS на сервере server1 не взаимодействует с GNS на сервере server2. Это означает, что при необходимости регистрации приложением на сервере server1 глобальной службы на клиентских узлах, процесс gns на сервере server1 не может направить этот запрос на сервер server2, поскольку процесс gns не функционирует как клиент и сервер одновременно. Однако это не влияет на приложения, выполняющие попытку подключения к данной службе, поскольку запрос направляется на оба сервера.

Автоматическое сканирование клиентов

Каждый менеджер GNS зарегистрирован по пути /dev/name/gns_server или /dev/name/gns_client. При запуске клиента GNS без присвоения целевого сервера выполняется автоматическое сканирование для поиска сервера(-ов) GNS в локальной сети.

На клиенте:

Автоматическое сканирование выполняется по каталогам локальной сети (обычно /net) для поиска путевого имени /net/компьютер/proc/mount/dev/name/gns_server.

Примечание. Автоматическое сканирование не является гарантией обнаружения сервера, т.к. в сети Qnet в каталоге /net могут находиться не все локальные компьютеры.

Автоматическое сканирование клиентов целесообразно при потере соединения с сервером. В этом случае для поиска сервера клиентом выполняется повторное сканирование. Это упрощает запуск другого сервера GNS и его синхронизацию с первым сервером (синхронизация рассматривается ниже), а также последующее уничтожение первого сервера GNS.

Если для клиента в командной строке указан конкретный сервер (конкретные серверы) GNS, то автоматическое сканирование не выполняется. При потере соединения с сервером он пытается восстановить соединение при каждом запросе на регистрацию, поиск или подключение.

Режим резервного сервера

Менеджер GNS можно запустить в режиме "резервный сервер". Для этого следует запустить менеджер GNS в режиме сервера и ввести конкретный серверный компьютер в командной строке.

В узле node1 запускается стандартный сервер:

Менеджер GNS на сервере node2 выполняет синхронизацию с менеджером GNS на сервере node1, получает всю информацию о глобальных службах из узла node1 и сохраняет ее локально.

Все клиенты GNS, уже подключенные к серверу GNS в узле node1, получают информацию о новом сервере в узле node2 и подключаются к нему. При этом для клиентов существует несколько серверов, аналогично выполнению запуска следующим образом:

# gns -c node1 node2

GNS и сеть с высокой степенью связности

Для сети с высокой степенью связности менеджер GNS можно запустить только в режиме сервера. Для всех клиентских узлов может использоваться префикс к пространству имен сервера вместо запуска менеджера GNS локально в режиме клиента.

На сервере:

Если поставщик_службы регистрирует имя глобальной службы из клиентского узла (без выполнения gns -c) информация направляется напрямую менеджеру GNS на сервер. Далее если потребитель_службы выполняет попытку поиска имени сервера, менеджеру GNS на сервер отправляется сообщение о поиске, которое возвращает данные поставщика службы.

Если поставщик регистрирует имя локальной службы, он просто регистрирует себя в менеджере локальных путей. Менеджер локальных путей обслуживает потребителя во время поиска локальной службы.

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

Кроме того, если указываются префиксы для пространства путевых имен, просмотр клиентом каталога /dev/name/net для определения узла, поставляющего службы, невозможен. Однако эта информация при выполнении обычных операций объявления/поиска не является важной.

Специальное путевое имя

Все менеджеры GNS зарегистрированы как /dev/name/gns_server или /dev/name/gns_client. Это путевое имя может содержать статистическую информацию об менеджере GNS. Пример:

Из этого примера следует, что процесс gns является клиентом одного сервера (компьютер с именем xtang); подключение к серверу уже установлено. Также перечислены все службы, известные менеджеру GNS. Обратите внимание, что для службы network/tcpip установлено ограничение срока действия, что свидетельствует о кэшировании этой записи в результате запроса сервера gns.

Примеры:

При использовании gns типичная сеть выглядит следующим образом:

Узел сервера:

Обратите внимание на способ регистрации /dev/name/global/printer/ps/techpub. Путь /dev/name/global/net зарезервирован менеджером gns (следовательно объявление приложением службы, запущенной как net/ невозможно). На компьютерах по пути /dev/name/global/net выполняется менеджер GNS. Например, в следующем списке менеджер GNS запущен на двух компьютерах:

Объявление одной службы может быть выполнено на нескольких серверах приложений на разных компьютерах. Поэтому одно путевое имя может соответствовать нескольким серверам. По этой причине менеджер GNS автоматически создает имя в формате nd идентификатор_процесса идентификатор_канала описатель тип_файла по зарегистрированному путевому имени:

Из этого примера можно сделать вывод о наличии двух приложений, связанных со службой printer/ps/techpub.

В некоторых случаях требуется определить, какую именно службу предоставляет компьютер netsrv.ott.qnx.com. Для этого можно просмотреть файл /dev/name/global/net/netsrv.ott.qnx.com, в котором перечислены службы, связанные процессом с netsrv.ott.qnx.com:

Из этого примера можно заключить, что процессом на компьютере xtang.ott.qnx.com с идентификатором процесса 16834613 зарегистрирована служба printer/ps/techpub. Эта же служба зарегистрирована и процессом 1826845 на компьютере netsrv.ott.qnx.com.