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

[Evgeny_CD]

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

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

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

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

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

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

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

3. Гибрид

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

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

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

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

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

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

[defunct]

Я прощу прощения если не в тему, но
Evgeny_CD а не приходила ли Вам мысль отказаться от операционки?
Чем дальше я читал эту ветку тем бесполезнее мне казалось ее применение.

По Вашим словам 1bit на 100 Гц (опрос охранки) - это низкая скорость, но и опрос этот как правило выполняет один Intel 80C51 (128 байт RAM, ~0.5MIPS @12Mhz).

Вы же планируете использовать ARM, LPC2138 - 60Mhz (59 32х битных MIPS)
20 Khz 8 bit, для 60-ти мегагерцового ARM'а - семечки. Ну смешно ведь ставить линукс лишь только для того чтобы использовать более дорой ARM контроллер и к тому же сделать его "тормознутым".

IP стек реализовать - плевое дело, гораздо проще чем разобраться с его реализацией в Linux
у меня с этим mega48 справлялся, походу обслуживая 16-ти разрядный стерео DAC @48kHz, тот самый проц который стоит меньше доллара по словам mse и который здесь почему-то используют только в качестве "сопроцессора для защиты софта".

Если планируется использование пром PC, то можно взять просто DOS (он сейчас тоже вроде как Free), и извращаться как душе будет угодно. Под DOS ведь тоже есть нормальный IP стек, например Microsoft Client 3, Trumpet-TCP и прочие.

PS: и по ходу MAC канального уровня, на котором строится траспорт (IP-стек) и сеансовый уровень (Sockets), обеспечивает доставку пакетов в том виде и в том порядке в котором пакеты были сформированы на транспортном уровне. Максимальный объем IP пакета определяется максимальным объемом MAC пакета и реализацией драйвера, и в большинстве случаев ограничивается 2-4kb.

[Evgeny_CD]

Я прощу прощения если не в тему, но
Evgeny_CD а не приходила ли Вам мысль отказаться от операционки?
Чем дальше я читал эту ветку тем бесполезнее мне казалось ее применение.

По Вашим словам 1bit на 100 Гц (опрос охранки) - это низкая скорость, но и опрос этот как правило выполняет один Intel 80C51 (128 байт RAM, ~0.5MIPS @12Mhz).

Нет. Ось нужна.

1. Проблема не в опросе, а в дальнейшей обработке. Например, Berkeley DB (http://dev.sleepycat.com/) я не возьмусь портировать под BigLoop, а база данных мне очень нужна.

2. DOS - "фтопку". Хоть free, хоть за деньги.

3. Мне надо, чтобы проект прожил 10 лет без кардинаьной смены идеологии, и мог много раз перескочить на разные аппаратные платформы.

Так что ОСь будет служить вовсе не для утяжеления основного контроллера.

[defunct]

1. Проблема не в опросе, а в дальнейшей обработке. Например, Berkeley DB (http://dev.sleepycat.com/) я не возьмусь портировать под BigLoop, а база данных мне очень нужна.

Весомый аргумент в пользу ОС.

3. Мне надо, чтобы проект прожил 10 лет без кардинаьной смены идеологии, и мог много раз перескочить на разные аппаратные платформы.

Ну а этот не совсем весомый

Опыт показывает, что независимо от сложности софта и ОС под которую он был написан, без особых усилий его можно перенести на другую аппаратную платформу, даже в том случае если софт этот был написнан не на C, а на asm'е или чем-нибудь еще. При условии, что перенос будет осуществляться той же командой разработчиков. А у Вас помоему ситуация еще проще, сами планируете писать софт, под самостоятельно разрабатываемый девайс. Imho при таком подходе лучше удешевлять на всю катушку аппаратную часть, вместо гонки за кроссплатформенностью. Хотя это только imho.

ЗЫ: а есть сомнения, что при индивидуальном подходе устройство продержится 10 лет? Или через 5 лет будет уже другая полоса звуковых частот? ;>

Сообщение отредактировал defunct - Jan 31 2006, 03:03

[Evgeny_CD]

Опыт показывает, что независимо от сложности софта и ОС под которую он был написан, без особых усилий его можно перенести на другую аппаратную платформу, даже в том случае если софт этот был написнан не на C, а на asm'е или чем-нибудь еще. При условии, что перенос будет осуществляться той же командой разработчиков. А у Вас помоему ситуация еще проще, сами планируете писать софт, под самостоятельно разрабатываемый девайс. Imho при таком подходе лучше удешевлять на всю катушку аппаратную часть, вместо гонки за кроссплатформенностью. Хотя это только imho.

ЗЫ: а есть сомнения, что при индивидуальном подходе устройство продержится 10 лет? Или через 5 лет будет уже другая полоса звуковых частот? ;>

Проблема вспомнить через 10 лет, что же ты тут такого написал . Разработка будет не индивидуальная, а силами небольшой команды. У нас уже есть примеры устройств на 87C51GB, которые прожили более 10 лет. И так хочется софт на них переписать, и так обломно ковыряться в асмовых исходиках (а софт там state of the art с точки зрения целевой задачи, его лет 5 по кусочкам писали и баги фиксили).