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

Политику качества обслуживания можно  определять как часть сетевого пути. Например /net/wintermute~redundant/dev/ser1. Политика должна всегда начинаться с символа «тильды». Для одной и той же сети с разными политиками качества обслуживания можно использовать символьные ссылки в каталоге «/net».

Давайте рассмотрим на примере, как  вышеописанные схемы работают на практике. Пример реальной сети на предприятии, состоящей из трех компьютеров А, B, C и удаленной ЭВМ, доступ к которой осуществляется через глобальную сеть (как пример — Интернет).

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

Теперь, A или C, при взаимодействии с B, обнаруживают, что они ничего не получают по одному из интерфейсов. Будет предпринята попытка протестировать интерфейс на некоторой очень низкой скорости передачи данных. До тех пор, пока кабель не будет вновь подключен к B, взаимодействие будет осуществляться с примерно ? пропускной способности по сравнению с изначальной. Время обнаружения выхода из строя соединения зависит от величины таймаута носителя и частоты транзакций (опрос не будет осуществляться, если нет невыполненных транзакций). Другой случай — интерфейс часто отказывает (например автокар переехал 10base5, но разъемы остались в сетевых платах). В этом случае, если потери скорости в интерфейсе превысят некоторое допустимое значение в процентах (например 5%), протокол транспортного уровня снизит скорость передачи данных, чтобы предпринять тестирование интерфейса.

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

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

За счет сетевой прозрачности мы можем отказаться от использования графического интерфейса и прикладного ПО, отвечающего за вывод информации на рабочем месте оператора — можно подгружать эти компоненты с ЭВМ, выполняющей функции подсистемы сбора информации через QNET. В результате, на рабочем месте оператора понадобятся только драйвера графики и ввода. Аналогично и с остальными компонентами системы. В результате мы сможем сократить и затраты на аппаратную часть всего комплекса.

Протокол 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)

lpFilter

В ОС 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.

Из сказанного следует, что сети типа QNET, являются хорошей альтернативой сетям типа Ethernet в распределенных системах для управления процессами в реальном времени.

Построение распределенных приложений

Ранее упоминалось, что наибольшую популярность получили Ethernet-сети с использованием стека протоколов TCP/IP. При построение таких приложений принято использовать многозвенную архитектуру, однако в рамках данной работы будем рассматривать ее упрощенную версию - клиент-серверную.

Так, согласно задания, необходимо разработать клиент-серверное приложение, в которое входит:

• Сервер, поддерживаетдо 4-х клиентских подключений.
• Клиент, может функционировать параллельно с несколькими такими же клиентами в одной сети и подключаться к заданному клиенту.

Алгоритм

Исходя из постановки задачи, необходимо описать алгоритм работы сразу 2-х  приложений:

• Сервера.
• Клиента.

Диаграмма последовательности взаимодействия клиента и сервера приведена  на рис. 1. На примере клиента 1 детализирован  весь жизненный цикл потока 1 по его обслуживанию.

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

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

 

На рис. 2 приведена блок-схема  алгоритма основного потока выполнения на сервере. После запуска процесса сервера, производится чтения файла  конфигурации:

• К какому IP адресу производится привязка.
• К какому порту производится привязка.
• Максимальное количество клиентов, которых необходимо обслужить.
• Имя файла лога, куда заносится информация о полученных пакетах

После прочтения файла конфигурации, производится проверка корректности параметров конфигурации. В случае их некорректности, производится завершение процесса сервера.

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

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

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

 

 

 

 

Рис. 8. Блок-схема основного потока сервера

 

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

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

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

 

Рис. 9. Блок-схема потока по обслуживанию клиентских подключений

 

Далее опишем алгоритм функционирования клиентского приложения. Клиент

Блок схема клиентского приложения представлена на рис. 4. Коротко опишем алгоритм работы приложения. После запуска, производится чтение из файла конфигурации:

• К какому IP адресу необходимо привязать клиентское приложение.
• Параметры закона формирования интервалов времени, через которые происходит генерация пакетов.
• Параметры закона формирования размеров пакетов.
• К какому IP адресу сервера необходимо подключаться.
• К какому порту сервера необходимо подключаться.

После чтения конфигурации, производится проверка ее корректности. В случае некорректности конфигурации происходит завершение приложения.

Рис. 10. Блок-схема алгоритма основного  потока клиента

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

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