Архитектура сервера для встроенного устройства

Question

Я работаю над серверным приложением для встроенной платформы ARM. Плата ARM подключена к различным цифровым IO, АЦП и т. Д., Которые система будет постоянно опрашивать. В настоящее время работает ядро ​​Linux с аппаратными интерфейсами, разработанными в качестве драйверов. Идея состоит в том, чтобы иметь клиентское приложение, которое может подключаться к встроенному устройству и получать сенсорные данные по мере их обновления и выдавать команды устройству (датчик выключения 1, датчик перезапуска 2 и т. Д.). Предположим, что доступ к сенсорным устройствам осуществляется через типичный ioctl.

Теперь мой вопрос касается дизайна / архитектуры этого серверного приложения, работающего на встроенном устройстве. Сначала я думал использовать что-то вроде libevent или libev , облегченных библиотек обработки событий на Си. Приложение установит приоритет события опроса датчика (и затем отправит информацию клиенту после завершения опроса) и обработает клиентские команды по мере их получения (через типичный сокет TCP). Сервер обычно имеет одно соединение, но может иметь до дюжины или около того, но не что-то вроде тысяч соединений. Это лучший подход к разработке чего-то подобного? Из двух перечисленных мной библиотек обработки событий одна лучше для встроенных приложений или есть другие альтернативы?

Другой рассматриваемый подход - это многопоточное приложение, в котором опрос датчика выполняется в приоритетном / блокирующем потоке, который считывает сенсорные данные, а каждое клиентское соединение обрабатывается в отдельном потоке. Сенсорные данные обновляются в своего рода структуру буфера / данных, и потоки соединения обрабатывают отправку данных клиенту и обработку клиентских команд (я предположил, что вам все равно понадобится цикл сортировки событий в этих потоках для отслеживания входящих команд) , Существуют ли какие-либо библиотеки или типичные пакеты, которые облегчают разработку такого приложения, или это то, что вы должны начать с нуля?

Как бы вы разработали то, что я пытаюсь достичь?

Answer 1

Я бы использовал сокет домена unix - и сам написал бы библиотеку, не вижу никаких преимуществ использования libvent, поскольку приложение привязано к linux, а libevent также предназначен для сотен соединений. Вы можете делать все, что вы пытаетесь сделать, с помощью одного потока в вашем демоне. ПОЦЕЛУЙ.

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

Что касается библиотек, вы, возможно, получите выгоду от буферов протокола Google (для сериализации и представления вашего протокола) - однако он поддерживает только первый класс для C ++ и по проводам (сериализация) Формат немного сдвигает бит в числовые данные. Я сомневаюсь, что это добавит каких-либо серьезных накладных расходов. Однако альтернативой является ASN.1 ( asn1c ).

Answer 2

Мое предложение будет измененной формой вашего второго предложения. Я хотел бы создать сервер, который имеет два потока. Один поток опрашивает датчики, а другой - для ВСЕХ ваших клиентских подключений. Я использовал во встроенных устройствах (MIPS) boost :: asio библиотеку с отличными результатами.

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

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