Вопрос ламера по Linux IPC, Inter Process Comminications Опции

[Evgeny_CD]

Есть два процесса под Linux. Им надо обмениваться пакетами данных.

Пакет представляет из себя:

* заголовок - поле фиксированной длины
* данные - поле переменой длины (<= MAX_LEN), заполненное бинарными
случайными данными.

Как лучше всего сделать такой обмен?

Я удумал следующее.

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

2. Разделяемая память. Наделать там кучу семафоров, и обмениться
указателями на структуры.

3. Гибрид

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

2 потока для каждого направления обмена.

Передающий процесс пишет в поток send_msg char значение номера
элемента в массиве, куда он положил пакет.

Принимающий процесс пишет в поток msg_ask char значение номера элемента в
массиве, который он прочитал (освободил).

IMHO, так еще будет быстрее всего (нет лишнего копирования) и
экономнее (по памяти) всего (нет памяти для лишних копий).

Вероятно, я изобретаю велосипед. А что скажут Гуру по данному поводу?

[zltigo]

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

Излишество :-) в качестве физического интерфеса за Socket естественно может выступать
и COM порт со штатной для операционки поддержкой SLIP/PPP. Вы уж определяйтесь - либо "большая"
операционка со всеми ее достоинствами (ну и недостатками которые придется принимать и любить, как родные ) либо более самодельное с соответствующими достоинствами. Смешивать, пожалуй, это порочный путь.

[Evgeny_CD]

Излишество :-) в качестве физического интерфеса за Socket естественно может выступать
и COM порт со штатной для операционки поддержкой SLIP/PPP. Вы уж определяйтесь - либо "большая"
операционка со всеми ее достоинствами (ну и недостатками которые придется принимать и любить, как родные ) либо более самодельное с соответствующими достоинствами. Смешивать, пожалуй, это порочный путь.

Согласен! Просто я немного изменил начальные условия.

Для решения целевой задачи мне надо оцифровывать входной сигнал с
относительно высокой скоростью - 20кгц. 8 бит. Далее первичная
обработка: выделение границ битов (на амплитудной шкале), перевод в
битовый поток, привязка блока битов к GPS времени, и передача в
основную Линух систему для серьезной обработки.

Понятно, что если я на ARM920 200 Мгц ядре забубеню 20 кгц интеррапты под
Линухом, тот тут все быстродействие системы и кончится. Можно и ДМА
прикрутить, но все равно останется довольно заметный объем низовых
вычислений. Хочется освободить от этого основное ядро системы.

Я всю первичную обработку загоню в какой-нибудь LPC2138 (ресурсов по
процу и памяти как раз хватит), а вот подготовленный данные буду гнать
по RS-485 в Linux машику.

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

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

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

Еще раз большое спасибо всем, кто потратил время на мое просвещение!!!

Сообщение отредактировал Evgeny_CD - Jan 17 2006, 15:56