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

[Evgeny_CD]

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

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

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

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

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

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

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

3. Гибрид

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

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

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

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

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

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

[zltigo]

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

Я НЕ ВСТРЕЧАЛ и ДУМАЮ НЕ ВСТРЕЧУ такого безобразия - это ФУНДАМЕНТ. Все мои замечания по этому поводу относятся только к тому что где-то кто-то что-то видел/слышал и по этой причине решил
добавить в механизм еще свою спичечку привязав ее веревочкой...
Для _высокоуровневых_ протоколов в массовых серьезных операционках - можете считать, что царит гармония. За поведение многочисленых "микроконтроллерных" стеков сделанных кем-то для использования в каких-то определеных условиях при использовании изделия в других РАЗНООБРАЗНЫХ условиях отвечать просто НЕВОЗМОЖНО.
Ну и еще замечание - если собираетесь базироваться на на *NIX ообразной открытой операционке для чего либо не являющегося настольной машиной с иксами - обратите свой взор в сторону FreeBSD.
Ее по крайней мере делает поименованый управляемый коллектив.

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

Это не Ваши знания :-( они разрознены и противоречивы местами. Дальше что? Монетку кидать?
На здравый смысл уповать? На книжку ссылаться? Только практика критерий истины.
И еще Ваш подход (это я базируясь на надбюдениях за другими темами) к делу поражает немалым размахом. Такая организация дела несомненно работает и по своему эффективна, но в БОЛЬШИХ
коллективах (ну начиная с полусотни разработчиков и прочего персонала на проект) с изрядным финансированием, для содержания оных. Это Ваш случай? Если нет, то все Ваши усилия на поддержание "установленного порядка" сожрут все ресурсы разработчиков.

[Evgeny_CD]

Ну и еще замечание - если собираетесь базироваться на на *NIX ообразной открытой операционке для чего либо не являющегося настольной машиной с иксами - обратите свой взор в сторону FreeBSD.
Ее по крайней мере делает поименованый управляемый коллектив.

Эта мысли меня уже посещала. Но стремно:
* спецов по BSD очень мало
* книжек тоже, хотя несколько книжек я уже утащил
* книжек по NetBSD вообще нет (я не нашел). По иее это самый что ни на есть embedded BSD
* хочется иметь ту же самую платфому на писюке и embedded девайсе. Хотя бы пока я учусь.

Потом, очень даже возможно, будут перепрыгивать на BSD.

Это не Ваши знания :-( они разрознены и противоречивы местами. Дальше что? Монетку кидать?
На здравый смысл уповать? На книжку ссылаться? Только практика критерий истины.
И еще Ваш подход (это я базируясь на надбюдениях за другими темами) к делу поражает немалым размахом. Такая организация дела несомненно работает и по своему эффективна, но в БОЛЬШИХ
коллективах (ну начиная с полусотни разработчиков и прочего персонала на проект) с изрядным финансированием, для содержания оных. Это Ваш случай? Если нет, то все Ваши усилия на поддержание "установленного порядка" сожрут все ресурсы разработчиков.

1. На умении выуживать знания из противоречивых данных и мнений я всю свою сознательную жизнь живу. Надеюсь, эта функция моего BIOS меня не подведет и сейчас. Главное, чтобы подсознание отработало. Я не будут завтра кодить сокеты. Но через пару недель, когда я этим займусь, у меня уже будет некая система реперных точек, которя сработает в нужный момент. Опытный факт, что мне это сэкономит массу времени и сил.

2. Замах большой, это так. И колектива 50 девелоперов (вместе с бюджетом) тоже нет. Но с годами я дозрел до практики downgrade. Т.е. когда задача осмысливается целиком, начиная с верхнего уровня. Потом я рисую схему сущностей проекта (листов 30 А4), и делаю безжалостную кастрацию всей красоты, оставив ГЛАВНОЕ, и "крючки" для навешивания всего остального.

Потом выдаю lite версию девелоперам, и постепенно это становится философией команды. И когда новички приходят - их есть чем учить.

В ходе длительных размышлений за последние полгода мне удалось нашупать контуры новой среды разработки. Там не так важен сокетный протокол, и даже embedded ось не так важна (а вот синтетически порт под Linux важен принципиально!), и важна именно идеология декомпозиции задачи и обеспечения связи между компонентами.

3. Дьявол таится в деталях. Я не сомневаюсь в этом! И проблем будет масса! Лично для меня важно понимать, что именно надо делать (иметь некое объектно-ориентированное мышление применительно к целевой задаче, когда важны методы , а вот конкретный "экземпляр класса" выстраивается по ситуации), а с самим деланием потихоньку разберемся. Мир не без добрых людей.

Спасибо Вам за Ваши ценнейшие замечания!