Исследование временных характеристик многопоточного приложения в ОСРВ QNX во время обработки информации от периферийных устройств

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

Структуры сети QNX.

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

Преимущества такой архитектуры:

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

• различные типы сетевых протоколов, такие как QNET и TCP/IP могут сосуществовать в системе одновременно;

В QNX Neutrino сетевая подсистема делится на три основные составляющие:

• менеджер сети (io-net), исполняемый модуль.
• интерфейс сетевого протокола (npm-qnet.so, npm-tcpip.so и т.д.) — разделяемые библиотеки.
• интерфейс драйвера сетевого оборудования (devn-ne2000.so) — разделяемые библиотеки.

Примерно так выглядит схема  взаимодействия приложения с аппаратным обеспечением. Компонент io-net может одновременно поддерживать несколько сетевых протоколов и несколько драйверов.

Менеджер сети io-net

Менеджер сети io-net выполняет ключевую функцию «моста» между интерфейсами сетевых протоколов и интерфейсами сетевых драйверов. Наибольшей гибкости удается достичь за счет независимости менеджера сети от используемых типов протоколов или аппаратной реализации сети. io-net подгружает протоколы и драйверы как динамические библиотеки, которые в свою очередь осуществляют взаимодействие с программой клиента через соответствующий API протокола и с железом через соответствующий API драйвера.

Интерфейс протокола передачи данных

Интерфейс протокола отвечает за реализацию того или иного протокола передачи данных, например таких как QNET, TCP/IP и др. Каждый интерфейс протокола поставляется в виде разделяемой библиотеки, например npm-qnet.so, протокол QNET, он же Native Neurino Networking. Одновременно в системе могут быть запущены один и более протоколов.

Например, следующая команда запускает  менеджер сети с двумя протоколами: io-net -d ne2000 -p ttcpip -p qnet

В комплект поставки QNX 6 входит четыре основных интерфейса сетевых протоколов:

• QNET - «родной» протокол ОС QNX,
• TTcpIp - «tiny» (крошечный) tcp/ip стек для встраиваемых приложений (только базовые функции tcp/ip),
• TcpIp - полная реализация TCP/IP стека от BSD 4.4 (BSD sockets API),
• Pppmgr - Point-to-Point протокол.

Интерфейс сетевого драйвера

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

io-net -d ne2000

запускает менеджер сети, который  в свою очередь подгружает интерфейс  драйвера сетевой платы NE2000, размещенный в виде динамической библиотеки devn-ne2000.so. Между драйвером и менеджером сети устанавливается двустороннее взаимодействие. Драйвер может обрабатывать вызовы от менеджера сети при приеме пакетов и, наоборот, менеджер сети, в свою очередь, обращается к драйверу при попытке осуществить передачу пакетов.

Компания QSSL (разработчик ОС QNX) относительно недавно выпустила в свет бета- версии комплектов разработчиков драйверов для своей ОС, в т.ч. сетевых. Комплект содержит примеры исходных текстов реально существующих сетевых драйверов и руководство программиста в формате PDF.

Протокол QNET

Native Neutrino Networking — это, прежде всего, высокоскоростной сетевой протокол. Уникальность QNET заключается в том, что он превращает объединенные в сеть компьютеры в один виртуальный суперкомпьютер (кластер), создавая единый однородный набор ресурсов, доступ к которым возможен из любого места сети. Следует заметить, что QNET предусматривает возможность наличия нескольких параллельных физических сетей. Для этого следует поместить в каждый компьютер несколько сетевых плат соединенных отдельными кабелями.

• FLEET расшифровывается как:
• Fault-tolerant — отказоустойчивость;
• Load-balancing on the fly — регулировка нагрузки на лету;
• Efficient performance — эффективное действие;
• Extensible architecture — расширяемая архитектура;
• Transparent distributed processing — прозрачная распределенная обработка.

Отказоустойчивость

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

 

Регулировка нагрузки на лету

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

Эффективное действие

Сетевые драйверы FLEET позволяют буквально «выжать» все возможное из сетевого оборудования. Например, при передаче больших блоков данных между двумя процессами по сети Ethernet достигает высокой пропускной способностью, см. таблица 1.

Таблица 1. Пропускная способность  по сети Ethernet через драйверы FLEET

Сеть	Пропускная способность
10 Mbit Ethernet	1.1 Mbytes/sec
100 Mbit Ethernet	7.5 Mbytes/sec

 

Расширяемая архитектура

Сетевые драйверы и менеджер сети не входят в ядро ОС и являются независимыми процессами, которые могут быть запущены или остановлены в любой момент. Компьютеры могут динамически подключаться к сети либо отсоединяться от нее не требуя реконфигурации системы. Благодаря автоматическому сетевому «мосту», можно объединять различные физические сети в одну логическую локальную сеть.

Рис. 5. Пример объединения нескольких разнородных сетей в единую логическую сеть

 

Распределенная обработка данных

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

Соглашения об именах узлов

Чтобы понять, как работает QNET, рассмотрим пример взаимодействия "клиент-сервер". В случае единственного узла (процессы клиента и сервера работают в рамках одного компьютера), клиент просто создает связь с сервером, используя функцию ConnectAttach(). Затем посылается сообщение, например, через MsgSend().

Теперь рассмотрим случай простой  сети с двумя машинами — одна содержит процесс- клиент, другая — процесс-сервер. Соглашение о связи клиент-сервер идентично соглашению в случае единственного узла. Клиент создает связь с сервером и посылает серверу сообщение. Единственное различие в случае сети — то, что клиент определяет другой дескриптор узла для запроса функции ConnectAttach ().

Как клиент узнает, какой именно дескриптор узла использовать для связи с  сервером?

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

И в том и в другом случаях, при соединении клиента с сервером, клиент получает идентификатор из ConnectAttach(). Этот идентификатор используется в дальнейшем при отправке/приеме сетевых сообщений.

Давайте рассмотрим, что произойдет в системе после выполнения функции open ().

Предположим, что клиент на одном  узле (magenta) желает использовать последовательный порт (/dev/ser1) на другом узле (wintermute). Клиент выполняет open(), указывая путь /net/wintermute/ dev/ser1.

Рассмотрим, что при этом произойдет:

1. Передача сообщения от клиента к местному менеджеру процессов. Осуществляется запрос, с кем войти в контакт, чтобы выполнить распознавание сетевого пути /net/wintermute/ dev/ser1. Т.к. менеджер сети работает через пространство имен "/net", менеджер процессов вернет сообщение о перенаправлении, указывающее, что клиент должен соединиться с локальным менеджером сети для получения дополнительной информации.
2. Клиент передает сообщение локальному менеджеру сети, заново запрашивая информацию о том, с кем он должен соединиться, в соответствии с именем сетевого пути. Локальный менеджер сети отвечает другим сообщением перенаправления, возвращая дескриптор узла, идентификаторы процесса и канала от менеджера процессов на узле wintermute.
3. Клиент создает связь с менеджером процессов на узле wintermute, еще раз запрашивая с кем нужно войти в контакт, согласно сетевому пути. Менеджер процессов на узле wintermute возвращает переадресацию, на сей раз с описателем узла, идентификаторами канала и процесса драйвера последовательного порта на его собственном узле.
4. Клиент создает связь с драйвером последовательного порта на узле wintermute, и, наконец, получает идентификатор, который можно использовать впоследствие для посылки/приема сообщений.

Теперь все сообщения клиент-сервер являются прямыми и проходят аналогично локальному случаю.

Терминология

Имя узла - Последовательность, идентифицирующая узел. Имя узла не может содержать "слешей" или "точек". В примере выше, использовали wintermute в качестве одного из имен узлов.

Доменное имя узла - Последовательность, присоединяемая npm-qnet к имени узла. Вместе имя узла и доменное имя должны образовывать единую последовательность. Доменное имя является уникальным для всех узлов, которые общаются друг с другом.

Полное сетевое имя узла (FQNN) - Полная последовательность, объединяющая вместе имя узла и доменное имя. Например, имя узла — wintermute, и доменное имя — qnx.com.ru, то полное сетевое имя будет: wintermute. qnx.com.ru.

Сетевой каталог - Каталог, имя которого определяется через npm-qnet. Каждый сетевой каталог (их может быть на одном узле больше одного) имеет предопределенное имя. По умолчанию — /net.

Распознавание имен - Процесс, с помощью которого npm-qnet конвертирует полные сетевые имена в список адресов, для того, чтобы транспортный уровень протокола знал маршрут.

Преобразование имен - Участок кода, осуществляющий преобразование полного сетевого имени в список конечных адресов. Каждый сетевой каталог имеет список преобразователей имен, которые в свою очередь используются для преобразования полных сетевых имен. По умолчанию — ndp.

Политика обслуживания (QoS)

Способ взаимодействия между двумя  узлами. По умолчанию QoS — loadbalance. Варианты преобразования имен:

Менеджер сети включает следующие типы преобразования:

• NDP — Node Discovery Protocol — посылает широковещательный запрос в сеть.
• DNS — к имени узла добавляется точка, результат передается функции TCP/IP gethostbyname ().
• File — ищет полное сетевое имя в статическом файле.

Качество обслуживания (QoS)

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

Сеть Neutrino предполагает следующие варианты QoS:

• Балансировка нагрузки (loadbalance). На уровне протокола npm-qnet принимаются решения, какие соединения использовать для передачи пакетов, в зависимости от текущей нагрузки и скорости передачи данных, определяемой io- net. Осуществляется попытка доставить пакеты, накопившиеся в очереди, как можно быстрее к удаленному узлу, используя все доступные и возможные физические соединения. Если возникает обрыв связи, периодически посылаются служебные пакеты с целью обнаружить восстановление соединения. Если соединение восстанавливается, оно включается в работу. Используется по умолчанию.

Рис. 6. Пример сети предприятия, с удаленным  компьютером

 

• Последовательный (sequential). Используется первое доступное соединение, до возникновения ошибки, тогда используется следующее доступное соединение, и так далее. Приоритеты соединений определяются пользователем. Как и с loadbalance QoS, вышедшие из строя соединения периодически проверяются на восстановление и, если соединение восстановлено, оно помещается в пул доступных соединений. Если используется соединение с меньшим приоритетом, и восстанавливается соединение с большим, то предпочтение отдается использованию соединения с большим приоритетом.
• Привилегированный (preferred). Аналогичен последовательному, с некоторыми отличиями. Когда последнее из списка доступных соединений, выходит из строя, включается политика loadbalance.
• Избыточный (redundant). Пакеты пересылаются по всем возможным соединениям одновременно. Если хотя бы одно соединение выходит из строя, то передача возобновляется только при восстановлении.