Библиотека сайта rus-linux.net
Проект GPSD
Глава 7 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: GPSD, глава из книги
"The Architecture of Open Source Applications" том 2
Автор: Eric Raymond
Перевод: Н.Ромоданов
7.2. Взгляд извне
Основной программой в наборе инструментальных средств GPSD является демон сервиса gpsd. Он может собирать данные, поступающие от набора подключенных датчиков устройств через соединения RS232, USB, Bluetooth, TCP/IP и UDP. Данные обычно поступают на порт 2947 на TCP/IP, но также могут поступать через совместно используемую память или интерфейс D-BUS.
Пакет GPSD поставляется с клиентскими библиотеками для языков C, C++ и Python. Он включает в себя образцы клиентских приложений на языках C, C++, Python и PHP. Клиентская сборка для Perl доступна через CPAN. Эти клиентские библиотеки не только удобны для разработчиков приложений; они также спасают разработчиков GPSD от головной боли, изолируя приложения от деталей сообщений JSON пакета GPSD. Таким образом, интерфейс API, предоставляемый клиентам, может оставаться такими же даже в случае, когда в протокол для новых типов датчиков добавляются новые возможности.
К числу других программ в наборе инструментальных средств относятся утилита низкоуровневого мониторинга устройств (gpsmon), профилировщик, который создает отчеты о статистике ошибок и синхронизации устройств (gpsprof), утилита настройки устройств (gpsctl), а также программа для потокового преобразования журнальных данных в удобочитаемый формат JSON (gpsdecode). Вместе они помогают технически подкованными пользователями заглянуть как можно глубже в работу присоединенных датчиков, работе которых у них вызывает беспокойство.
Конечно, эти инструментальные средства также помогают самим разработчикам проекта GPSD проверять правильность работы gpsd. Одним из самых важных тестовых инструментальных средств является gpsfake, средство тестирования gpsd, которое можно подключить к журнальным файлам любого количества датчиков так, как будто бы они являются реальными устройствами. С помощью gpsfake мы можем повторно запустить журнальный файл датчика, полученный вместе с сообщением об отказе, и воспроизводить конкретные проблемы. gpsfake также является движком нашего обширного инструментального средства, предназначенного для регрессионных тестов, которое снижает затраты на модификацию программного обеспечения благодаря более простому обнаружению изменений, из-за которых возникает проблема.
Одним из самых важных уроков, который, как мы думаем, мы получили для будущих проектов, состоит в том, что недостаточно, чтобы набор инструментальных средств был корректным, должна также быть возможность продемонстрировать его правильность. Мы обнаружили, что, когда эта цель реализуется должным образом, она будет не маскировочной сеткой, а парой крыльев — время, которое мы затрачиваем на написание нагрузочных и регрессионных тестов, будет многократно окупаться сторицей благодаря той свободе, которая позволяет нам изменять код, не опасаясь, что мы создадим трудно обнаруживаемый беспорядок в существующих функциональных возможностях.
7.3. Слои программного обеспечения
Внутри GPSD происходит гораздо больше того, чем могут предположить люди, знающие на практике, что нужно «подключить датчик и он просто заработает». Внутренняя структура gpsd естественным образом делится на четыре части: драйверы, анализатор пакетов, основную библиотеку и мультиплексор. Мы опишем эти части, рассматривая их снизу вверх.
Рис.7.1: Слои программного обеспечения
Драйверы являются, в сущности, драйверами устройств пользовательского пространства для каждого вида чипсетов датчиков, которые мы поддерживаем. Основным их ключевыми элементами являются методы анализа пакетов данных и получения информации о времени, позиции скорости или состоянии датчиков, изменения их режимов работы или скорости передачи данных, определения подтипов устройств и т.д. Вспомогательные методы могут поддерживать операции управления драйверами, например, изменение скорости последовательного обмена данными с устройством. Весь интерфейс драйвера является структурой на языке C, заполненной указателями на данные и методы, которая преднамеренно имитирует структуру драйверов устройств в Unix.
Анализатор пакетов отвечает за получение пакетов данных из последовательных входных потоков. Это, большей частью, машина состояний или конечный автомат, который наблюдает за всем, что выглядит как один из наших 20 или около того известных типов пакетов (в большинстве из них есть контрольная сумма, так что когда мы говорим, что обнаружили один из них, мы говорим это с высокой уверенностью). Поскольку устройства могут подключаться в режиме горячей замены или изменять режимы, тип пакета, поступающего из последовательного порта или порта USB, не обязательно постоянно будет совпадать с типом первого пакета.
Основная библиотека (core library) осуществляет управление сессией работы с устройством-датчиком. Основными ключевыми аспектами являются следующие:
- открытие сессии с помощью открытия устройства и чтения данных из него, перебор комбинаций скорости передачи и значений четности/стопового бита до тех пор, пока анализатор пакетов не будет синхронизирован с известным ему типом пакета;
- опрос устройства, получающего пакеты, и
- закрытие устройства и завершение сессии.
Ключевой особенностью основной библиотеки является то, что она отвечает за то, чтобы для каждого подключения GPS использовался правильный драйвер устройства, зависящий от типа пакетов, возвращаемого анализатором пакетов. Это не настраивается заранее и может изменяться с течением времени, особенно если в устройстве есть возможность переключения между различными протоколами (в большинство чипсетов GPS поддерживается протокол NMEA и один или несколько двоичных протоколов, предоставляемых поставщиком, а а такие устройства, как AIS, могут по одному и тому же проводу пересылать пакеты, использующие два различных протокола).
Наконец, мультиплексор является частью демона, который работает с сессиями клиентов и назначением устройств. Он отвечает за передачу сообщений клиентам, принимая команды клиента и реагируя на сообщения о горячих подключениях. В сущности, все это задается в одном исходном файле gpsd.c и никакое из заданий не обращается к драйверам устройств напрямую.
Первые три компонента (кроме мультиплексора) компонуются друг с другом в библиотеке с названием libgpsd и ими можно пользоваться отдельно от мультиплексора. Наши прочие инструментальные средства, с помощью которых происходит непосредственное общение с датчиками, например, gpsmon и gpsctl, осуществляют это с помощью непосредственного обращения к основной библиотеке и слою драйверов.
Наиболее сложным отдельным компонентом является анализатор пакетов, имеющий размер около двух тысяч строк кода. Их количество сократить нельзя; конечный автомат, который может распознавать такое количество различных протоколов, как это он делает, обязательно будет большим и запутанным. К счастью, анализатор пакетов также легко изолировать и протестировать; проблемы, имеющиеся в нем, не будут влиять на другие части кода.
Слой мультиплексора имеет приблизительно такой же размер, но он немного менее запутанный. Основную часть демона составляют драйверы устройств - около 15 тыс. строк. Оставшаяся часть кода - все средства и библиотеки поддержки вместе с инструментальными средствами тестирования клиентов - вместе по размеру равны примерно размеру демона (некоторый код, в частности парсер JSON, используется совместно как в демоне, так и в клиентских библиотеках).
Преимущество такого подхода, использующего слои, демонстрируется несколькими способами. Во-первых, поскольку драйверы для новых устройств писать легко, некоторые из них были отданы на разработку лицам, не входящим в основную команду разработчикам: интерфейс API драйвера документирован, а отдельные драйверы подключаются к основной библиотеке только через указатели, расположенные в главной таблице типов устройств.
Еще одним преимуществом является то, что системные интеграторы могут резко сократить размер GPSD при использовании во встроенных системах, просто решив не компилировать неиспользуемые драйверы. Демон для начала не так уж и велик и сборка, урезанная соответствующим образом, работает вполне нормально на маломощных низкоскоростных устройствах ARM, не обладающих большим количеством памяти. ARM является RISC архитектурой с 32-битным набором команд, используемой в мобильных устройствах и во встраиваемой электронике. Смотрите http://en.wikipedia.org/wiki/ARM_architecture.
Третье преимущество слоев состоит в том, что мультиплексор демона может быть отсоединен от основной библиотеки и заменен простой логикой, например, такой, которая в потоке преобразует сообщения, поступающие в журнальный файл, в сообщения JSON, т.е. именно то, что делает утилита gpsdecode.
В этой части архитектуры GPSD нет ничего нового. Ее урок состоит в том, что сознательное и строгое применение шаблона проектирования, предназначенного для устройств Unix, приносит пользу не только в ядре ОС, но и в пользовательских программах, в которых они также необходимы при работе с разнообразными аппаратными средствами и протоколами.