Сетевые возможности ОСРВ QNX
введение
В простейшем случае локальная сеть обеспечивает разделяемый доступ к файлам и периферийным устройствам для нескольких соединенных между собой компьютеров. Операционная система QNX идет гораздо дальше этого простейшего представления и объединяет всю сеть в единый, однородный набор ресурсов.
Любой процесс на любом компьютере в составе сети может непосредственно использовать любой ресурс на любом другом компьютере. С точки зрения приложений не существует никакой разницы между местным или удаленным ресурсом, и использование удаленных ресурсов не требует каких-либо специальных средств. Более того, чтобы определить, находится ли такой ресурс как файл или устройство на локальном компьютере или на другом узле сети, в программу не потребуется включать специальный дополнительный код!
Пользователи могут иметь доступ к файлам по всей сети, использовать любое периферийное устройство, запускать программы на любом компьютере сети (при условии, что они имеют надлежащие полномочия). Связь между процессами осуществляется единообразно, независимо от их местоположения в сети. В основе такой прозрачной поддержки сети в QNX лежит всеобъемлющая концепция InterProcess Communication (IPC) — взаимодействие между отдельными процессами на основе передачи сообщений.
модель единого компьютера
QNX изначально проектировалась как сетевая операционная система. В некоторых отношениях сеть QNX напоминает скорее большую ЭВМ, нежели набор мини-компьютеров. Однако, в отличие от большой ЭВМ, "единый компьютер" QNX обеспечивает гораздо более быструю реакцию системы, т.к. соответствующий объем вычислительных ресурсов может быть выделен на каждом узле в соответствии с потребностями каждого пользователя.
В условиях управления производством используются программируемые контроллеры и другие устройства ввода/вывода, работающие в режиме реального времени, которые могут потребовать больше ресурсов, чем другие менее ответственные приложения, такие как, например, текстовый редактор. Сеть QNX достаточно "отзывчива", чтобы поддерживать оба этих типа приложений одновременно — QNX позволяет сфокусировать вычислительную мощность системы на производственном оборудовании там, где это необходимо, не жертвуя в то же время интерфейсом пользователя.
гибкая поддержка сети
Сеть QNX может быть построена с использованием различного оборудования и стандартных промышленных протоколов. В силу своей полной прозрачности для прикладных программ и пользователей, новые сетевые архитектуры могут быть внедрены и исключены динамически, в любое время, не нарушая при этом целостности операционной системы и не прерывая ее работы.
Такая степень прозрачности является еще одним примером больших возможностей архитектуры QNX, основанной на передаче сообщений (IPC). Во многих операционных системах такие важные функции как поддержка сети и IPC выполнены в виде надстроек над операционной системой, а не интегрированы непосредственно в ее сердцевину. Результатом такого подхода является неуклюжий и неэффективный интерфейс с "двойным стандартом", когда связь между процессами — это одно дело, в то время как проникновение в скрытый интерфейс таинственного монолитного ядра — совершенно другое дело!
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, ttcpip, tcpip, pppmgr.
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 достигается:
распределенная обработка данных
Поддержка сети 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, и, наконец, получает идентификатор, который можно использовать впоследствие для посылки/приема сообщений.
Теперь все сообщения клиент-сервер являются прямыми и проходят аналогично локальному случаю.
Последовательный (sequential)
Используется первое доступное соединение, до возникновения ошибки, тогда используется следующее доступное соединение, и так далее. Приоритеты соединений определяются пользователем. Как и с loadbalance QoS, вышедшие из строя соединения периодически проверяются на восстановление и, если соединение восстановлено, оно помещается в пул доступных соединений. Если используется соединение с меньшим приоритетом, и восстанавливается соединение с большим, то предпочтение отдается использованию соединения с большим приоритетом.
Привилегированный (preferred)
Аналогичен последовательному, с некоторыми отличиями. Когда последнее из списка доступных соединений, выходит из строя, включается политика loadbalance.
Избыточный (redundant)
Пакеты пересылаются по всем возможным соединениям одновременно. Если хотя бы одно соединение выходит из строя, то передача возобновляется только при восстановлении.
Политику качества обслуживания можно определять как часть сетевого пути. Например /net/wintermute~redundant/dev/ser1. Политика должна всегда начинаться с символа "тильды". Для одной и той же сети с разными политиками качества обслуживания можно использовать символьные ссылки в каталоге "/net".
Давайте рассмотрим на примере, как вышеописанные схемы работают на практике. Пример реальной сети на предприятии, состоящей из трех компьютеров А,B,C и удаленной ЭВМ, доступ к которой осуществляется через глобальную сеть (как пример — Интернет).
Предположим, что все доступные соединения используются в режиме балансирования нагрузки. A, B, и C при взаимодействии между собой используют пропускную способность обеих сетей, чем обеспечивается в данном случае наибольшая производительность (Рис. 1). Теперь представим, что один из соединительных кабелей, идущих к B, отсоединен (Рис. 2).
Теперь, A или C, при взаимодействии с B, обнаруживают, что они ничего не получают по одному из интерфейсов. Будет предпринята попытка протестировать интерфейс на некоторой очень низкой скорости передачи данных. До тех пор, пока кабель не будет вновь подключен к B, взаимодействие будет осуществляться с примерно ? пропускной способности по сравнению с изначальной. Время обнаружения выхода из строя соединения зависит от величины таймаута носителя и частоты транзакций (опрос не будет осуществляться, если нет невыполненных транзакций). Другой случай — интерфейс часто отказывает (например автокар переехал 10base5, но разъемы остались в сетевых платах). В этом случае, если потери скорости в интерфейсе превысят некоторое допустимое значение в процентах (например 5%), протокол транспортного уровня снизит скорость передачи данных, чтобы предпринять тестирование интерфейса.
Предположим, что С взаимодействует с внешней машиной. Для связи могут использоваться оба соединения с узлом А, который выступает в этом случае в качестве шлюза. Теперь рассмотрим этот пример с использованием избыточной политики. При применении избыточной политики в локальной сети ни один из узлов не сможет установить связь с внешней машиной если хотя бы одно соединение в локальной сети будет повреждено. Поэтому нужно быть весьма осторожным при применении в данном случае политики избыточности, гораздо выгоднее использовать другие методы, возможно loadbalance или последовательный.
Экономический эффект от применения QNET, по сравнению с традиционными сетевыми технологиями, выражается в сокращении затрат на программные и аппаратные средства при проектировании конкретных узлов сети и является прямым следствием свойств прозрачной сетевой поддержки.
На рис. 3 приведена структурная схема возможной организации АСУ некого объекта с применением ОС QNX Neutrino, но с использованием традиционных сетевых технологий, например TCP/IP. Система состоит из трех компьютеров соответственно один из них установлен непосредственно на объекте, осуществляет взаимодействие с аппаратной частью системы, первичную обработку показаний датчиков, второй выполняет функции подсистемы сбора и обработки полученной информации, в т.ч. накопление результатов в базе данных, третий установлен на рабочем месте оператора, осуществляющего удаленное управление технологическим процессом и мониторинг параметров.
На рис. 4 та же схема, но с использованием технологии QNET и удаленной сетевой загрузки bootp/tftp. За счет использования технологии удаленной загрузки, поддерживаемой в QNX Neutrino, мы можем отказаться от использования драйверов файловых систем на узлах рабочего места оператора и на машине, установленной на объекте автоматизации.
За счет сетевой прозрачности мы можем отказаться от использования графического интерфейса и прикладного ПО, отвечающего за вывод информации на рабочем месте оператора — мы будем подгружать эти компоненты с ЭВМ, выполняющей функции подсистемы сбора информации через QNET. В результате, на рабочем месте оператора нам понадобятся только драйвера графики и ввода. Аналогично и с остальными компонентами системы. В результате мы сможем сократить и затраты на аппаратную часть всего комплекса.
А если вообще несколько отвлеченно от темы этого материала взглянуть на структурную схему, несложно заметить, что все три ЭВМ являют собой по сути дела уровни автоматизации различной иерархии. Но все они выполнены на базе одной ОС — QNX Neutrno.
протокол TCP/IP
С ростом Internet, все более широкораспространенным становится протокол, основанный на — IP (Internet, протокол). Даже если Вы не подключаетесь к Internet, все равно, протокол IP и базирующиеся на нем инструментальные средства, общеприменимы и в результате IP-протокол становится де факто для многих частных сетей.
IP используется от простых задач (удаленный вход в систему) до более сложных (например поставка биржевых цен в реальном масштабе времени). И, сейчас, достаточно сложно найти ОС, в которой не было бы средств поддержки IP-протокола.
Для удовлетворения большинства пользовательских требований, QSSL разработала "облегченный" стек Neutrino TCP/IP (npm-ttcpip), с целью уменьшить затраты ресурсов, по сравнению с использованием обычного BSD API.
Neutrino TCP/IP также соответствует концепции модульности, принятой в QNX. Например, клиент NFS реализован в виде отдельного модуля и т.п. Именно принцип модульности в Neutrino TCP/IP позволил разработчикам эффективно и быстро проектировать и создавать встраиваемые системы, ориентированные на использование IP-протокола.
структура
Интерфейс протокола npm-ttcpip разработан в виде многопоточного ресурс-менеджера. За счет использования мультипоточности стало возможным одновременное обслуживание большого количества клиентов.
В Neutrino TCP/IP используется BSD-совместимый socket-API. Это обеспечивает совместимость как с другими Unix-системами, так и с Windows. С практической точки зрения это позволяет безболезненный перенос сетевых приложений для TCP/IP из этих ОС в ОС Neutrino.
функции разрешения имен
Функции базы данных имен были изменены, в сторону лучшего соответствия потребностям встраиваемых систем.
/etc/resolv.conf
Информация, обычно содержащаяся в/etc/resolv.conf может быть помещена в переменную среды RESCONF. Это позволяет использовать сервер имен без /etc/resolv.conf. Это также касается вызовов gethostbyname () и других функций преобразования имен.
/etc/protocols
В функции Getprotobyname () и getprotobynumber () были внесены изменения для обеспечения поддержки нескольких протоколов, включая IP, ICNP, UDP, и TCP. Для большинства случаев это означает, что можно обойтись без файла /etc/protocols.
/etc/services
Функция Getservbyname () была подвержена изменениям с целью поддержки нескольких сервисов, включая ftp, telnet, smtp, domain, nntp, netbios-ns, netbios-ssn, sunrpc, и nfsd. Для большинства случаев это означает, что можно обойтись без файла /etc/services.
способность к взаимодействию
Код npm-ttcpip реализует функциональные возможности, предложенные в RFC 1122, ARP, IP, ICMP, UDP, и поддерживает протоколы TCP. npm-ttcpip также обеспечивает поддержку DHCP.
Мы не будем здесь рассматривать подробно состав пакета TCP/IP, об этом достаточно много и так написано. Остановимся лишь на особенностях реализации, исключительных для QNX Neutrino.
встраиваемый сервер slinger
Отдельно имеет смысл рассмотреть входящий в состав пакета TCP/IP компактный веб-сервер slinger — собственная разработка QSSL, предназначенный для применения во встраиваемых приложениях. Он поддерживает возможности SSI и CGI, что позволяет, например, при применении в контроллерах, выдавать по запросу определенную информацию в виде динамических HTML-документов на рабочее место оператора. Это позволяет значительно сократить расходы на разработку клиентского программного обеспечения на рабочем месте оператора, осуществляющего, например, мониторинг параметров технологического процесса.
Организация рабочего места оператора сводится к установке компьютера с ОС, поддерживающей TCP/IP и содержащей в себе веб-браузер.
полнофункциональный TCP/IP Stack
В состав ОС также входит реализация протокола TCP/IP, полностью соответствующая BSD 4.4 sockets. Это полнофункциональный TCP/IP протокол npm-tcpip. Включает в себя модуль NFS сервера, поддержку multicasting, virtual packet interface и т.д. Идеален для использования при решении таких задач, как, например, организация полнофункционального интернет-узла.
Здесь следует заметить, что приложения, удовлетворяющие API npm-ttcpip, сохранят свою работоспособность и под управлением полнофункционального стека npm-tcpip без какой либо модификации или рекомпиляции.
фильтры (nfm-xxx)
IpFilter
В ОС Neutrino уже реализованы программные средства, расширяющие возможности TCP/IP до профессиональных. К таким средствам можно отнести модуль IPFilter. Программа распространяется с исходным кодом. Позволяет реализовать такие функции, как собственно фильтрация IP-пакетов, Firewall (что немаловажно на стыке глобальной сети и внутренней сети предприятия), NAT и комбинации вышеперечисленных возможностей.
Berkley Packet filter
Существует в стадии внутренней бета-версии QSSL. Применяется в библиотеке libcap, использующейся например для реализации сниффера пакетов tcpdump. Пользователь, используя фильтры собственной разработки, может значительно расширить существующие возможности TCP/IP в ОС QNX Neutrino.
софт
Если говорить о программном обеспечении для TCP/IP в QNX Neutrino, то его уже достаточно много. Это как разработки "с нуля" так и софт, перенесенный из других *nix-совместимых ОС. Вкратце попробую перечислить наиболее важные из них. Это веб-серверы Apache 1.3.x, Boa, популярный FTP-сервер ProFTPD, прокси-сервер squid, текстовые и графические браузеры, ICQ-, IRC- и FTP-клиенты. Большое количество программного обеспечения, распространяемого под лицензией GNU, также перенесено в среду QNX Neutrino.
Дмитрий Васильев
В простейшем случае локальная сеть обеспечивает разделяемый доступ к файлам и периферийным устройствам для нескольких соединенных между собой компьютеров. Операционная система QNX идет гораздо дальше этого простейшего представления и объединяет всю сеть в единый, однородный набор ресурсов.
Любой процесс на любом компьютере в составе сети может непосредственно использовать любой ресурс на любом другом компьютере. С точки зрения приложений не существует никакой разницы между местным или удаленным ресурсом, и использование удаленных ресурсов не требует каких-либо специальных средств. Более того, чтобы определить, находится ли такой ресурс как файл или устройство на локальном компьютере или на другом узле сети, в программу не потребуется включать специальный дополнительный код!
Пользователи могут иметь доступ к файлам по всей сети, использовать любое периферийное устройство, запускать программы на любом компьютере сети (при условии, что они имеют надлежащие полномочия). Связь между процессами осуществляется единообразно, независимо от их местоположения в сети. В основе такой прозрачной поддержки сети в QNX лежит всеобъемлющая концепция InterProcess Communication (IPC) — взаимодействие между отдельными процессами на основе передачи сообщений.
модель единого компьютера
QNX изначально проектировалась как сетевая операционная система. В некоторых отношениях сеть QNX напоминает скорее большую ЭВМ, нежели набор мини-компьютеров. Однако, в отличие от большой ЭВМ, "единый компьютер" QNX обеспечивает гораздо более быструю реакцию системы, т.к. соответствующий объем вычислительных ресурсов может быть выделен на каждом узле в соответствии с потребностями каждого пользователя.
В условиях управления производством используются программируемые контроллеры и другие устройства ввода/вывода, работающие в режиме реального времени, которые могут потребовать больше ресурсов, чем другие менее ответственные приложения, такие как, например, текстовый редактор. Сеть QNX достаточно "отзывчива", чтобы поддерживать оба этих типа приложений одновременно — QNX позволяет сфокусировать вычислительную мощность системы на производственном оборудовании там, где это необходимо, не жертвуя в то же время интерфейсом пользователя.
гибкая поддержка сети
Сеть QNX может быть построена с использованием различного оборудования и стандартных промышленных протоколов. В силу своей полной прозрачности для прикладных программ и пользователей, новые сетевые архитектуры могут быть внедрены и исключены динамически, в любое время, не нарушая при этом целостности операционной системы и не прерывая ее работы.
Такая степень прозрачности является еще одним примером больших возможностей архитектуры QNX, основанной на передаче сообщений (IPC). Во многих операционных системах такие важные функции как поддержка сети и IPC выполнены в виде надстроек над операционной системой, а не интегрированы непосредственно в ее сердцевину. Результатом такого подхода является неуклюжий и неэффективный интерфейс с "двойным стандартом", когда связь между процессами — это одно дело, в то время как проникновение в скрытый интерфейс таинственного монолитного ядра — совершенно другое дело!
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 подгружает протоколы и драйверы как динамические библиотеки, которые в свою очередь осуществляют взаимодействие с программой клиента через соответствующий API протокола и с железом через соответствующий API драйвера.
интерфейс протокола передачи данных
Интерфейс протокола отвечает за реализацию того или иного протокола передачи данных, например таких как QNET, TCP/IP и др. Каждый интерфейс протокола поставляется в виде разделяемой библиотеки, например npm-qnet.so, протокол QNET, он же Native Neurino Networking. Одновременно в системе могут быть запущены один и более протоколов.
Например, следующая команда запускает менеджер сети с двумя протоколами:
io-net -d ne2000 -p ttcpip -p qnet
В комплект поставки QNX 6 входит четыре основных интерфейса сетевых протоколов. Это qnet, ttcpip, tcpip, pppmgr.
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 достигается:
| Сеть | Пропускная способность |
| 10 Mbit Ethernet | 1.1 Mbytes/sec |
| 100 Mbit Ethernet | 7.5 Mbytes/sec |
расширяемая архитектура
Сетевые драйверы и менеджер сети не входят в ядро ОС и являются независимыми процессами, которые могут быть запущены или остановлены в любой момент. Компьютеры могут динамически подключаться к сети либо отсоединяться от нее не требуя реконфигурации системы. Благодаря автоматическому сетевому бриджингу, можно объединять различные физические сети в одну логическую локальную сеть.
распределенная обработка данных
Поддержка сети 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. Осуществляется попытка доставить пакеты, накопившиеся в очереди, как можно быстрее к удаленному узлу, используя все доступные и возможные физические соединения. Если возникает обрыв связи, периодически посылаются служебные пакеты с целью обнаружить восстановление соединения. Если соединение восстанавливается, оно включается в работу. Используется по умолчанию.
Последовательный (sequential)
Используется первое доступное соединение, до возникновения ошибки, тогда используется следующее доступное соединение, и так далее. Приоритеты соединений определяются пользователем. Как и с loadbalance QoS, вышедшие из строя соединения периодически проверяются на восстановление и, если соединение восстановлено, оно помещается в пул доступных соединений. Если используется соединение с меньшим приоритетом, и восстанавливается соединение с большим, то предпочтение отдается использованию соединения с большим приоритетом.
Привилегированный (preferred)
Аналогичен последовательному, с некоторыми отличиями. Когда последнее из списка доступных соединений, выходит из строя, включается политика loadbalance.
Избыточный (redundant)
Пакеты пересылаются по всем возможным соединениям одновременно. Если хотя бы одно соединение выходит из строя, то передача возобновляется только при восстановлении.
Политику качества обслуживания можно определять как часть сетевого пути. Например /net/wintermute~redundant/dev/ser1. Политика должна всегда начинаться с символа "тильды". Для одной и той же сети с разными политиками качества обслуживания можно использовать символьные ссылки в каталоге "/net".
Давайте рассмотрим на примере, как вышеописанные схемы работают на практике. Пример реальной сети на предприятии, состоящей из трех компьютеров А,B,C и удаленной ЭВМ, доступ к которой осуществляется через глобальную сеть (как пример — Интернет).
Предположим, что все доступные соединения используются в режиме балансирования нагрузки. A, B, и C при взаимодействии между собой используют пропускную способность обеих сетей, чем обеспечивается в данном случае наибольшая производительность (Рис. 1). Теперь представим, что один из соединительных кабелей, идущих к B, отсоединен (Рис. 2).
Теперь, A или C, при взаимодействии с B, обнаруживают, что они ничего не получают по одному из интерфейсов. Будет предпринята попытка протестировать интерфейс на некоторой очень низкой скорости передачи данных. До тех пор, пока кабель не будет вновь подключен к B, взаимодействие будет осуществляться с примерно ? пропускной способности по сравнению с изначальной. Время обнаружения выхода из строя соединения зависит от величины таймаута носителя и частоты транзакций (опрос не будет осуществляться, если нет невыполненных транзакций). Другой случай — интерфейс часто отказывает (например автокар переехал 10base5, но разъемы остались в сетевых платах). В этом случае, если потери скорости в интерфейсе превысят некоторое допустимое значение в процентах (например 5%), протокол транспортного уровня снизит скорость передачи данных, чтобы предпринять тестирование интерфейса.
Предположим, что С взаимодействует с внешней машиной. Для связи могут использоваться оба соединения с узлом А, который выступает в этом случае в качестве шлюза. Теперь рассмотрим этот пример с использованием избыточной политики. При применении избыточной политики в локальной сети ни один из узлов не сможет установить связь с внешней машиной если хотя бы одно соединение в локальной сети будет повреждено. Поэтому нужно быть весьма осторожным при применении в данном случае политики избыточности, гораздо выгоднее использовать другие методы, возможно loadbalance или последовательный.
Экономический эффект от применения QNET, по сравнению с традиционными сетевыми технологиями, выражается в сокращении затрат на программные и аппаратные средства при проектировании конкретных узлов сети и является прямым следствием свойств прозрачной сетевой поддержки.
На рис. 3 приведена структурная схема возможной организации АСУ некого объекта с применением ОС QNX Neutrino, но с использованием традиционных сетевых технологий, например TCP/IP. Система состоит из трех компьютеров соответственно один из них установлен непосредственно на объекте, осуществляет взаимодействие с аппаратной частью системы, первичную обработку показаний датчиков, второй выполняет функции подсистемы сбора и обработки полученной информации, в т.ч. накопление результатов в базе данных, третий установлен на рабочем месте оператора, осуществляющего удаленное управление технологическим процессом и мониторинг параметров.
На рис. 4 та же схема, но с использованием технологии QNET и удаленной сетевой загрузки bootp/tftp. За счет использования технологии удаленной загрузки, поддерживаемой в QNX Neutrino, мы можем отказаться от использования драйверов файловых систем на узлах рабочего места оператора и на машине, установленной на объекте автоматизации.
За счет сетевой прозрачности мы можем отказаться от использования графического интерфейса и прикладного ПО, отвечающего за вывод информации на рабочем месте оператора — мы будем подгружать эти компоненты с ЭВМ, выполняющей функции подсистемы сбора информации через QNET. В результате, на рабочем месте оператора нам понадобятся только драйвера графики и ввода. Аналогично и с остальными компонентами системы. В результате мы сможем сократить и затраты на аппаратную часть всего комплекса.
А если вообще несколько отвлеченно от темы этого материала взглянуть на структурную схему, несложно заметить, что все три ЭВМ являют собой по сути дела уровни автоматизации различной иерархии. Но все они выполнены на базе одной ОС — QNX Neutrno.
протокол TCP/IP
С ростом Internet, все более широкораспространенным становится протокол, основанный на — IP (Internet, протокол). Даже если Вы не подключаетесь к Internet, все равно, протокол IP и базирующиеся на нем инструментальные средства, общеприменимы и в результате IP-протокол становится де факто для многих частных сетей.
IP используется от простых задач (удаленный вход в систему) до более сложных (например поставка биржевых цен в реальном масштабе времени). И, сейчас, достаточно сложно найти ОС, в которой не было бы средств поддержки IP-протокола.
Для удовлетворения большинства пользовательских требований, QSSL разработала "облегченный" стек Neutrino TCP/IP (npm-ttcpip), с целью уменьшить затраты ресурсов, по сравнению с использованием обычного BSD API.
Neutrino TCP/IP также соответствует концепции модульности, принятой в QNX. Например, клиент NFS реализован в виде отдельного модуля и т.п. Именно принцип модульности в Neutrino TCP/IP позволил разработчикам эффективно и быстро проектировать и создавать встраиваемые системы, ориентированные на использование IP-протокола.
структура
Интерфейс протокола npm-ttcpip разработан в виде многопоточного ресурс-менеджера. За счет использования мультипоточности стало возможным одновременное обслуживание большого количества клиентов.
В Neutrino TCP/IP используется BSD-совместимый socket-API. Это обеспечивает совместимость как с другими Unix-системами, так и с Windows. С практической точки зрения это позволяет безболезненный перенос сетевых приложений для TCP/IP из этих ОС в ОС Neutrino.
функции разрешения имен
Функции базы данных имен были изменены, в сторону лучшего соответствия потребностям встраиваемых систем.
/etc/resolv.conf
Информация, обычно содержащаяся в/etc/resolv.conf может быть помещена в переменную среды RESCONF. Это позволяет использовать сервер имен без /etc/resolv.conf. Это также касается вызовов gethostbyname () и других функций преобразования имен.
/etc/protocols
В функции Getprotobyname () и getprotobynumber () были внесены изменения для обеспечения поддержки нескольких протоколов, включая IP, ICNP, UDP, и TCP. Для большинства случаев это означает, что можно обойтись без файла /etc/protocols.
/etc/services
Функция Getservbyname () была подвержена изменениям с целью поддержки нескольких сервисов, включая ftp, telnet, smtp, domain, nntp, netbios-ns, netbios-ssn, sunrpc, и nfsd. Для большинства случаев это означает, что можно обойтись без файла /etc/services.
способность к взаимодействию
Код npm-ttcpip реализует функциональные возможности, предложенные в RFC 1122, ARP, IP, ICMP, UDP, и поддерживает протоколы TCP. npm-ttcpip также обеспечивает поддержку DHCP.
Мы не будем здесь рассматривать подробно состав пакета TCP/IP, об этом достаточно много и так написано. Остановимся лишь на особенностях реализации, исключительных для QNX Neutrino.
встраиваемый сервер slinger
Отдельно имеет смысл рассмотреть входящий в состав пакета TCP/IP компактный веб-сервер slinger — собственная разработка QSSL, предназначенный для применения во встраиваемых приложениях. Он поддерживает возможности SSI и CGI, что позволяет, например, при применении в контроллерах, выдавать по запросу определенную информацию в виде динамических HTML-документов на рабочее место оператора. Это позволяет значительно сократить расходы на разработку клиентского программного обеспечения на рабочем месте оператора, осуществляющего, например, мониторинг параметров технологического процесса.
Организация рабочего места оператора сводится к установке компьютера с ОС, поддерживающей TCP/IP и содержащей в себе веб-браузер.
полнофункциональный TCP/IP Stack
В состав ОС также входит реализация протокола TCP/IP, полностью соответствующая BSD 4.4 sockets. Это полнофункциональный TCP/IP протокол npm-tcpip. Включает в себя модуль NFS сервера, поддержку multicasting, virtual packet interface и т.д. Идеален для использования при решении таких задач, как, например, организация полнофункционального интернет-узла.
Здесь следует заметить, что приложения, удовлетворяющие API npm-ttcpip, сохранят свою работоспособность и под управлением полнофункционального стека npm-tcpip без какой либо модификации или рекомпиляции.
фильтры (nfm-xxx)
IpFilter
В ОС Neutrino уже реализованы программные средства, расширяющие возможности TCP/IP до профессиональных. К таким средствам можно отнести модуль IPFilter. Программа распространяется с исходным кодом. Позволяет реализовать такие функции, как собственно фильтрация IP-пакетов, Firewall (что немаловажно на стыке глобальной сети и внутренней сети предприятия), NAT и комбинации вышеперечисленных возможностей.
Berkley Packet filter
Существует в стадии внутренней бета-версии QSSL. Применяется в библиотеке libcap, использующейся например для реализации сниффера пакетов tcpdump. Пользователь, используя фильтры собственной разработки, может значительно расширить существующие возможности TCP/IP в ОС QNX Neutrino.
софт
Если говорить о программном обеспечении для TCP/IP в QNX Neutrino, то его уже достаточно много. Это как разработки "с нуля" так и софт, перенесенный из других *nix-совместимых ОС. Вкратце попробую перечислить наиболее важные из них. Это веб-серверы Apache 1.3.x, Boa, популярный FTP-сервер ProFTPD, прокси-сервер squid, текстовые и графические браузеры, ICQ-, IRC- и FTP-клиенты. Большое количество программного обеспечения, распространяемого под лицензией GNU, также перенесено в среду QNX Neutrino.
Дмитрий Васильев
Сетевые решения. Статья была опубликована в номере 04 за 2001 год в рубрике software
