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

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

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

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

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

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

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

3. Гибрид

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

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

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

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

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

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

Самое простое и безобидное через сокеты. Заодно и потом можно и на разные машины разнести
без всяких усилий.

С сокетами отчасти понятно. Но непонятно, как из потока выделять загловки пакетов? Или просто читать (и писать) блоками фиксированой длины, понимая, что в TCP сокете ничего потеряться не должно.

Значит с сокетами не понятно :-(.
Это _пакетный_ интерфейс.

Спасибо! Ну что же, будем вчитываться дальше.

Если один процесс родительский, а второй его потомок - лучше использовать pipe.
Если два независимых - то каналы FIFO. Кстати - каналы FIFO обеспечивают атомарные запись/чтение. Т.е. пакеты(кадры) не перемешиваются, в отличие например от передачи через TCP. Видимо это то что нужно.
Для разделяемой памяти существует ограничение на количество блоков разделяемой памяти для процесса (что-то около 20, но это зависит от системы и ее настроек).
Еще можно обмениваться через файлы, отображаемые в память.

Лучшая книга - Уильям Стивенс
Unix. Взаимодействие процессов Уильям Стивенс. Unix. Взаимодействие процессов

1. Pipe и FIFO суть одно и то-же и работают одинаково. И оба
исключительно НЕ пакетные - не сохраняют границ сообщений (вспоминаем о чем речь шла).
FIFO принадлежность System-V базирующихся систем и в линейке BSD не
используются по причине нахренненужности.
2. Ну не надо сюда TCP приплетать и пугать "перемешиванием" путая его с повтором.
3. FIFO как раз и есть файл "отображаемый на память", как и сокет при адресации AF_UNIX.

> 1. Pipe и FIFO суть одно и то-же и работают одинаково.
Не одно и то же, хотя бы с точки зрения того, что я говорил выше.

> И оба исключительно НЕ пакетные - не сохраняют границ сообщений (вспоминаем о чем речь шла).
pipe возможно, насчет FIFO не уверен. Поскольку с FIFO могут работать и несколько процессов.

> FIFO принадлежность System-V базирующихся систем и в линейке BSD не используются по причине нахренненужности.
Разговор вроде был о Linux, а не о фрях.

> 2. Ну не надо сюда TCP приплетать и пугать "перемешиванием" путая его с повтором.
Возможно я неправильно выразился, я имел ввиду, что TCP - не гарантирует сохранения границ пакетов. Неудачный пример.

> 3. FIFO как раз и есть файл "отображаемый на память", как и сокет при адресации AF_UNIX.
С точки зрения реализации - наверное да, но все-таки это разные механизмы IPC.

Выше вы говорили, что:

Продолжаю утверждать, что с этой точки зрения отличий Pipe и FIFO НЕТ НИКАКИХ.

?????

Речь идет о многочисленных последователей вышеупомянутых. BSD Socket предоставляет
продуманный унифицированый интерфейс. По этой причине присутствует повсеместно, в отличие
от FIFO.

И это утверждение тоже ложное. TCP/IP/UDP пакетные по определению. По условиям
канала передачи могут биться на более мелкие, но доставляются пользователю исключительно
монолитными.

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

Имелось ввиду что:
Для канала дочерний процесс может получть дескриптор только от процесса родителя. Каналы не могут использоваться в качестве IPC между независимыми процессами.
Очередь FIFO - отдельный тип файла в файловой системе, со всеми вытекающими. Не используются в BSD.
Вообще, много чего разного, при похожести в первом приближении.

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

Не верите - спросите у Робачевского и Ко.



В смысле прикладных пакетов, которые пользователь посылает. Подразумевалась вроде работа на прикоадном уровне? Прикладной уровень не всегда может забрать свой пакет полностью. Небольшим пакетам (по-моему до 8 КБ) это кстати не грозит - я же сказал пример неудачный.


В nix вообще идеологически все построено на файлах. С этой точки зрения и каналы FIFO, и локальные сокеты, и совместно используемые "файлы, отображаемые в память" (ну не помню я как этот тип IPC правильно называется) суть одно и то же. Но есть тонкости, которые определяющие - Поэтому один механизм IPC называется так, а другой эдак.

Кстати реализация BSD сокетов в каких либо облегченных версиях Linux тоже не совсем обязательно присутствует.

Если я в чем-то и ошибаюсь - всему виной моя недостаточная осведомленность.

Всех благ!

Насчет выделения пакетов из какого угодно потока (в том числе ненадежного) - че за трабла :

#define MAGIC 0xFEEDBEEF

struct Header {
int magic;
int len; // длина данных после заголовка
int cmd; // тип пакета
// ... всяческие полезные поля
int crc; // црц данных
} __attribute__ ((packed));

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

А в ipc вообше-то messag'ы есть такие - ими говорят очень удобно обмениваться ... Я так и не понял - процессы на одной машине ? В смысле нафига IPC заворачивать ?

1. За тем, что процессы изолированы во многих OC.
2. IPC для этого в OC и создаются, причем с учетом минимизации побочных эффектов.
3. Ну а в предложенной (к делу не относящейся реализации) рассчитывать на то, что DEADBEEF не встретится, и синхронизироваться ценой потери нескольких фреймов, конечно можно....., но радиолюбительство. Простейший надежный вариант формирования фрейма в байтовом потоке, например, в SLIP протоколе.

И это утверждение тоже ложное. TCP/IP/UDP пакетные по определению. По условиям
канала передачи могут биться на более мелкие, но доставляются пользователю исключительно
монолитными.
[quote]

Я уже кучу денег заработал исправляя программы которые пользуются TCP/IP как пакетным протоколом. (Особенно wireless)
Вот выдержка из RFC которая прямо об этом и предупреждает.

------------------------------------------

As for your second issue, please remember the admonition in RFC 1123:


" 4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34


" Implementors MUST NOT assume any correspondence between READ
boundaries on the control connection and the Telnet EOL
sequences (CR LF).


" DISCUSSION:
" Thus, a server-FTP (or User-FTP) must continue reading
characters from the control connection until a complete
Telnet EOL sequence is encountered, before processing
the command (or response, respectively). Conversely, a
single READ from the control connection may include
more than one FTP command."

Сначала к проблеме передачи пакета прицепили ни к селу ни к городу TCP/IP уровень, потом
на него навернули Telnet протокол и его паковку байтов в пакеты.... Для кучи приплели радиоканал....

Перестаньте пожалуйста морочить голову.

Vikladivayu knizku na /upload/doc/Unix_Linux_books :

Interprocess Communications in Linux®: The Nooks & Crannies
By John Shapley Gray

Publisher : Prentice Hall PTR
Pub Date : January 13, 2003
ISBN : 0-13-046042-7


Copyright
Introduction
Acknowledgments
Chapter 1. Programs and Processes
Section 1.1. Introduction
Section 1.2. Library Functions
Section 1.3. System Calls
Section 1.4. Linking Object Code
Section 1.5. Managing Failures
Section 1.6. Executable File Format
Section 1.7. System Memory
Section 1.8. Process Memory
Section 1.9. The u Area
Section 1.10. Process Memory Addresses
Section 1.11. Creating a Process
Section 1.12. Summary
Section 1.13. Key Terms and Concepts

Chapter 2. Processing Environment
Section 2.1. Introduction
Section 2.2. Process ID
Section 2.3. Parent Process ID
Section 2.4. Process Group ID
Section 2.5. Permissions
Section 2.6. Real and Effective User and Group IDs
Section 2.7. File System Information
Section 2.8. File Information
Section 2.9. Process Resource Limits
Section 2.10. Signaling Processes
Section 2.11. Command-Line Values
Section 2.12. Environment Variables
Section 2.13. The /proc Filesystem
Section 2.14. Summary
Section 2.15. Key Terms and Concepts

Chapter 3. Using Processes
Section 3.1. Introduction
Section 3.2. The fork System Call Revisited
Section 3.3. exec's Minions
Section 3.4. Using fork and exec Together
Section 3.5. Ending a Process
Section 3.6. Waiting on Processes
Section 3.7. Summary
Section 3.8. Key Terms and Concepts

Chapter 4. Primitive Communications
Section 4.1. Introduction
Section 4.2. Lock Files
Section 4.3. Locking Files
Section 4.4. More About Signals
Section 4.5. Signal and Signal Management Calls
Section 4.6. Summary
Section 4.7. Key Terms and Concepts

Chapter 5. Pipes
Section 5.1. Introduction
Section 5.2. Unnamed Pipes
Section 5.3. Named Pipes
Section 5.4. Summary
Section 5.5. Key Terms and Concepts

Chapter 6. Message Queues
Section 6.1. Introduction
Section 6.2. IPC System Calls: A Synopsis
Section 6.3. Creating a Message Queue
Section 6.4. Message Queue Control
Section 6.5. Message Queue Operations
Section 6.6. A Client–Server Message Queue Example
Section 6.7. Message Queue Class
Section 6.8. Summary
Section 6.9. Key Terms and Concepts

Chapter 7. Semaphores
Section 7.1. Introduction
Section 7.2. Creating and Accessing Semaphore Sets
Section 7.3. Semaphore Control
Section 7.4. Semaphore Operations
Section 7.5. Semaphore Class
Section 7.6. Summary
Section 7.7. Key Terms and Concepts

Chapter 8. Shared Memory
Section 8.1. Introduction
Section 8.2. Creating a Shared Memory Segment
Section 8.3. Shared Memory Control
Section 8.4. Shared Memory Operations
Section 8.5. Using a File as Shared Memory
Section 8.6. Shared Memory Class
Section 8.7. Summary
Section 8.8. Key Terms and Concepts

Chapter 9. Remote Procedure Calls
Section 9.1. Introduction
Section 9.2. Executing Remote Commands at a System Level
Section 9.3. Executing Remote Commands in a Program
Section 9.4. Transforming a Local Function Call into a Remote Procedure
Section 9.5. Debugging RPC Applications
Section 9.6. Using RPCGEN to Generate Templates and a MAKEFILE
Section 9.7. Encoding and Decoding Arbitrary Data Types
Section 9.8. Using Broadcasting to Search for an RPC Service
Section 9.9. Summary
Section 9.10. Key Terms and Concepts

Chapter 10. Sockets
Section 10.1. Introduction
Section 10.2. Communication Basics
Section 10.3. IPC Using Socketpair
Section 10.4. Sockets: The Connection-Oriented Paradigm
Section 10.5. Sockets: The Connectionless Paradigm
Section 10.6. Multiplexing I/O with select
Section 10.7. Peeking at Data
Section 10.8. Out of Band Messages
Section 10.9. Summary
Section 10.10. Key Terms and Concepts

Chapter 11. Threads
Section 11.1. Introduction
Section 11.2. Creating a Thread
Section 11.3. Exiting a Thread
Section 11.4. Basic Thread Management
Section 11.5. Thread Attributes
Section 11.6. Scheduling Threads
Section 11.7. Using Signals in Threads
Section 11.8. Thread Synchronization
Section 11.9. Thread-Specific Data
Section 11.10. Debugging Multithreaded Programs
Section 11.11. Summary
Section 11.12. Nomenclature and Key Concepts

Appendix A. Using Linux Manual Pages
Section A.1. Manual Page Sections
Section A.2. Manual Page Format
Section A.3. Standard Linux System Calls

Appendix B. UNIX Error Messages
Appendix C. RPC Syntax Diagrams
Section C.1. Introduction
Section C.2. RPC Definitions
Section C.3. RPC Keywords
Section C.4. Some RPC Examples

Appendix D. Profiling Programs
Section D.1. Introduction
Section D.2. Sample Program for Profiling
Section D.3. Generating Profile Data
Section D.4. Viewing and Interpreting Profile Data

Appendix E. Bibliography

Спасибо!

Спасибо всем просветившим меня!

Из всего многообразия IPC мне приглянулись сокеты, т.к. они более
универсальны, и позволяют разнести задачи по разным машинам (сейчас
это не надо, но на следующем этапе точно потребуется). Так что
имеет смысл брать именно их.

Но они не гарантирует сохранения границ моих блоков данных.

Прикрутить формирователь фреймов из SLIP - это круто, но не хочется.
Хочется по простому...

Моя следующая идея.

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

Далее процесс повторяется.

Как эта идея?

Я для этой цели использовал простой "самодельный" протокол:
-----
02 байта тип пакета
02 байта длина данных
хх Данные
-----
Пакеты садятся в буффер, первый пакет "выдёргивается", всё остальное сдвигается к началу + проверки.
На первый взгляд, довольно нудно парсить, но как показала практика способ удобный.
Позволяет легко разделять "слипшиеся" пакеты (TCP NODELAY не везде работает).
Проверяется всего один сокет (всего один вызов select())

А можно ещё проще, опять по одному сокету:
На каждую посылку принимать подтверждение (длина и тип естественно в заголовке), тупо! но действенно.

Думал я об этом. Вроде препятствий нет - TCP должен по идее гарантировать:
* доставку байтов
* сохранениех их порядка
* отсутствие дупов

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

Приняли как описано - засунули в структуру (данные апроксимируем массивом максимальной длины). "Провернули" буфер указателей.

Обработчики пакетов с другой стороны "проворачивают буфер" и разбираются с содержимым структуры.

Один трабл - синхронность запуска и остановки процессов. В варианте разных машин это може быть не так примитивно.

Вероятно, надо сделать гибрид. Ввести все таки контрольный сокет, по нему буквально однобатный обмен: типа приняли 0x55 - вычитали сокет до конца, выкинули эти данные, обресетили state machine и начали все сначала. В ответ по контрольному сокету можно 0xАА кинуть - типа обресетился, готов.

За идею!

Обалдеть.

А можно узнать, от чего? Если я какое ламерство написал - поянилите, плиз! Все-таки, сокеты сохраняют границы пакетов или нет? Я в литературе пока информации о сохранении границ не нашел.

Вообще-то для обеспечения прозрачности передаваемых данных существует такое дело как байтстаффинг: договариваются о некотором управляющем символе, присутствие которого означает, что следующий за ним символ - команда. Если следующий символ - также управляющий символ, значит эти два символа интерпретируются как один символ данных равный управляющему символу. Немного сумбурно написал, но смысл такой:
0x10 0x12 - управляющий символ 0x10, команда 0x12(смысл которой например начало или конец пакета)
0x10 0x10 - данные 0x10
В качестве управляющего символа естественно лучше всего брать наименее вероятный в потоке данных.
Собственно нечто подобное в SLIP и реализовано.

Ну так вот при перемещении фрагмента кадра в кольцевой буфер этот байтстаффинг и делается.
При этом кольцевой буфер является именно [b]кольцевым буфером символов[b], а не кольцевым буфером кадров/пакетов.

Для обработки пакетов при копировании из буфера сокетов в буфер символов создается управляющая структура типа


которая ставится в очередь и после обрабатывается в фоновом потоке.

Удачи!

1. Да я много написал. Потом оставил одно слово.

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

2. По конкретному вопросу о сохранении (если естественно не SOCK_STREAM )- сохраняют,
для этого и делалось. Отвечать за отсутствие ГРУБЕЙШИХ ошибок в многочисленных реализациях я естественно не могу, но СОХРАНЯЮТ.
3. Использование TCP уровня взамодействия в пределах одной машины перебор. TCP имеет смысл при работе именно черт знает через что (этому определению безхозный интернет полностью
соответствует ). Плата за "гарантированую доставку" _полная_ потеря реального времени и потеря произвольного (но порядка десятков килобайт) количества пакетов до получения хоть какого-то
намека на развал соединения. В принципе вышеописанное не является "родовым пятном", просто
реализации в 'больших системах' (линукс, вынь) давно плюют на обработку ошибок транспортного уровня и ограничиваются (в лучшем случае) только фиксацией факта для статистики. Производители
железок тоже пошли по этому (пусть с проблемами протоколы высокого уровня разбираются) пути.
Правда такая ситуация породила и рынок альтернативных стеков и самодельных надстроек
над UDP или RAW. Лично я пользуюсь для встроенных систем самообжитым IP стеком с обработкой
аппаратных ошибок, что при работе в _локальной_ сети с _правильным_ железом хабов/свичей
позволяет без потерь доставлять UDP датаграммы. При необходимости более жесткого
реального времени, большей простоты (со строны контроллера) и меньшей непредсказуемости конкретной реализации IP стека и драйверов на "больших" машинах - пользуюсь самодельным протоколом на фрейме IEEE 802.3 по мотивам IEEE 802.2. Со стороны "больших" реализуется как надстройка над RAW Socket.

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

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

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

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

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

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

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

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

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

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

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

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

1. Ну по большому счету их под Линукс мало, если не считать спецов уровня "инсталляторов
Windows". Массовые программисты разницы ПРОСТО НЕ ПОЧУВСТВУЮТ. Ну разбираться в
железках/драйверочках (впрочем помнится с железом проблем к Вас не предвидится) в BSD
заметно приятнее.
2. Ну книжки... С простыми вопросами и без них разберетесь, а готового рецепта выхода из сложной
ситуации Вы в них не найдете - НЕ ДЛЯ ЭТОГО ИХ ПИШУТ. А исходники BSD много читабельнее,
нежели то болото в которое превратились многочиленные Линуксы.
3. А может просто возьмете "кувалду побольше" (помнится я уже намекал на SOM-144, например)
и получите без проблем с портированием (и сопровождением оного) почти одинаковые системы. Причем, если Вы полагаете, что если на десктопе и на какой-нибудь железке с ARM9 будет одна операционка по причине того, что там и там она спекулирует раскрученным словечком Линукс, то это совсем не так
:-(
Сколько там контроллеров с 'линуксом' в год предполагается выбрасывать на рынок?

Конечно, оси на дектопе и контроллере будет разные. Но, если у них одинаковые версии ядра, то базовые интерфейсы, по идее, должны совпадать. Я собственно, на это и надеюсь.

SOM-144 - привлекательная вещь, я про них очень хорошо помню, и цены не очень безумные. Но я пока на нашел их Industrial, и, боюсь, цены там как раз будут неразумные.

Для прототипов, где мне будут нужны x86, буду использовать это
http://www.icop.com.tw/products_category.asp?CategoryID=2

По моим оценками Intel PXA270 600 Мгц мне должно хватить на ближайщие проекты на несколько лет вперед. Но хочется иметь позможность "спуска вниз", посему попробую все-таки целевой осью сделать eCos. Собственно, будет использован аналог SOM-144 от
http://www.toradex.com/e/Products_Colibri_..._Pentium_M.html

Контроллеров будет от 100 до 1к в год - как дело пойдет.

Ядро по исходникам изучать пока не готов

1-2 Тут есть много вариантов.
3. Синхронизация происходит ценой потери _одного_ неполного, на момент подключения к каналу, фрейма.

Это если Вы всегда, постоянно ищите помянутое 4x байтовое магическое значение и тем самым
начисто исключаете его наличие в потоке для других целей. Но мне помнится там у Вас еще и размер
поминался? Из чего я сделал вывод, что внутри фрейма указанного размера магическое значение
НЕ ищется.. А иначе зачем размер еше гонять?

Считаем:
1. Потеряли байтик - потеряли первый фрейм
2. Не нашли в ожидаемом месте магическое значение - начинаем искать - теряем второй фрейм
3. Встретилось нештатное магическое значение - продолжаем терять...

Естественно, ценой хранения предыдущего фрейма можно выкрутиться с п.2, но цена выкрутиться
будет еще и всплеск затрат времени в ранее гладком алгоритме (а байтики то об этом не знают
и продолжают идти..., что в некоторых случаях (речь не про сокеты) может потребовать еще и буфера для сырого потока). В случае c байт/бит стаффингом всегда имеем простой алгоритм с абсолютно предсказуемыми максимальными затратами времени на выделение фрейма и отсутствие необходимости
в дополнительных буферах для запоминания чего-либо на случай проблем. Может оказаться немаловажным и тот факт, что имеем ВСЕГДА одинаково БЕЗ ИСКЛЮЧЕНИЙ работающий алгоритм, а
в случае с волшебными словами еще придется писать и тестировать ветки поведения
при ошибках. Это конечно не "бином Ньютона", но ошибиться можно :-( а оно это надо?

Цены для моего случая - порядка 300 в год просто безвариантно привлекательнее самоделки,
для 1000, полагаю тоже. Тем более, что никто самоделку потом поставить не запретит.

На счет Industrial (отсутствия???) чего-то не понял...


Ну а по книжкам! :-)
Примерно в 2000 году на русском языке были изданы (DiaSoft помнится) две книжки, что-то типа
"Ядро Linux в комментариях" и "IP стек в комментариях". Уровень софта вполне соответствует ныешнему
контроллерному. Может увлечет чтение?
У меня обе есть в бумажном варианте (только не под рукой) при необхобходимости могу дать
полные выходные данные.

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

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

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

Поиск маджика происходит в _остутствии_ синронизации, потом только проверка, то что описано у Вас это просто бездарная реализация, человеческий алгоритм приблизительно таков - реализуем peek_data(int len, char *buf) и read_data(int len, char *buf)

1. peek(sizeof маджик)) - не он - скипаем байт, goto 1
2. он -ждем заголовок пакета, он у нас стандартной длины, проводим проверки (можно проверить валидность поля длины, црц и т.д.) и если проверка не прошла скипаем sizeof(magic), goto 1
3. проверка прошла - ждем данные - проверяем црц - не совпала - скипаем sizeof(magic), goto 1
4: синхронизация установлена

И того теряем хвост 1 неполного пакета - устойчивость приема, в худшем случае (когда поток из одних маджиков например) определяется только качеством ф-ции црц

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

Советую на досуге еще подумать над вариантами, причинами и следствиями.

Пусть теоретики на своими прожектами думают - мне больше по душе прагматичная скорость практического подхода

На том и порешили - каждый сам себе Буратино.

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

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

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

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

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

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

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

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

Даже такой отторможенный арм как 920 должон легко взять планку в 20-50 кгц, см. adeos/xenomai latency test/examples.
Стандартный инженерный подход в определении границы софт-хард должен подразумевать владение/прикид цифр на имеющемся железе в парочке вариантовю Все равно, как показывает практика, решений одной и той же задачи бывает несколько - дело обычно в эстетизьме ... или в лени ...

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

Обработка входных данных алгоритмически проста, но вычислений немало.

В то же время, LPC2138 под управлением замечательной ОСи BigLoop все это сделает точно. И тогда под Linux с могу спокойно писать обработку верхнего уровня - которая как раз алгоритмически сложна, хотя объем вычислений там невелик. И я смогу написать все это, заботясь о простоте и красоте кода, и не очень думать производительности.

Папка есть, а где же книга? То есть, где она в /pub/?


Нашел: /pub/DOC/Books/OS/Unix_linux/Interprocess_Communication_in_Linux.chm. Спасибо makc и _artem_!

> оцифровывать входной сигнал с относительно высокой скоростью - 20кгц. 8 бит.

вы имеели в виду оцифровку видеосигнала? или я не понял почему эта скорость
высокая.

Нет, я говорю об аналоговых НЧ сигналах. Скорость _относительно_ высокая. Относительно, например, 1-битной оцифровки 100 гц, которой хватает для опроса датчиков охранной системы

А вы не пробовали поискать девкиты работающие под QNX? если конечно построение распределённой системы не есть ваша конечная цель, то в пределах одного проца решать задачи всегда лучше. Стандартный линукс не осилит прерывания 20КГц, а QNX - вполне.

...ь любой софт - не проблема. Найти правильное решение - вот проблема.

Я тщательно изучал вопрос полгода и пришел к выводу, что для моих задач (вероятно, и для многих других задач) вместо того, чтобы решать вопрос о том, какая полуOS/полумух потянет 20 Кгц прерывания, гораздо правильнее поставить ATmega48 за 1.2$, оцифровывать там, кучковать данные в пакеты, приписывать к каждому пакету метку реального времени, и загонять эти данные в *nix контроллер по стандартному интерфейсу (RS, Ethernet, CAN, ...). В правильной *nix системе затраты процессорного времени на блочный IO по стандартным каналам невелики, а что касается "решать задачи всегда лучше" - понятно, что на том же линухе приятнее программить, чем под uCOS.

Что касается аппаратуры - AT91RM9200 просто гениальный проц со своей кучей коммуникационных контроллеров и DMA. К нему можно подцепить десяток этих ATmega48 вообще без проблем и лишней аппапаратуры (хотя, сказать по честному, AT91SAM7S32 за 4$ со своим SSC и DMA подходит куда лучше) А вот заниматься поиском ответа на вопрос: "Какая высокоуровневая OS потянет 200 Кгц прерывание?" и "4ГГц процессора хватит для этого?" я просто принципиально не буду.

Вам виднее, кто кроме вас вашу задачу знает? Если необходим именно десяток удалённых процессоров и система не может быть спроектирована в рамках одного, то конечно же вы правы. Но если вы хотите синхронизировать все эти процессы при помощи linux ipc на десятках килогерц, то возможно вы не сможете так решить свою задачу. Реалтайм (или близкие) синхронизации в qnx на мой взгляд выполнить удобнее. Спорить конечно не имеет смысла, в этом вы тоже правы.

QNX хорошя штука, но дорогая и не очень гибкая. Кроме того, я недолюбливаю решения, от которых у меня нет исходников. Естественно, я не собираюсь (пока?) править исходники ядра Linux и eCos (хотя ничего страшного тем нет), но сам факт их наличия греет мне душу.

Линукс насколько я вижу мигрирует к десктопу быстрее, чем к embedded устройствам. И пользуюсь я им только по той причине, что прерываний 5..10Кгц в нынешней постановке моих задач хватает. Да, среда удобная, мне тоже нравится что она открытая. Но влезать в реализацию ядра не имею никакого желания, поэтому что полузакрытость QNX, что открытость линукса - это в определённой степени одно и то же. То есть и в QNX и в линуксе вам как разработчику до определённого уровня задач и не нужно думать о ядерной реализации, а работать только с процессами (ipc о которых вы и спрашивали). А если для вас синхронизация с более высокой частотой критична, придётся связываться с реалтаймовыми патчами ядра линукса, что не факт будет лучше чем пользоваться готовым и сертифицированным (!) продуктом. имхо.

Чистый Linux тосклив для embedded - это правда. Есть масса веток, ориентированных на embedded приложения - они куда интереснее.

Я все-таки постраюсь, чтобы IPC у меня использовался для медленных "сущностей" - десятки мс.

Есть такая чудная штука - RTAI (rtai.org). IMHO, она крайне перспективна, и вот ее и хочется освоить. Вопрос сертификации меня не волнует. Я уже много раз высказывал мнение, что сертификация к качеству продукта отношения не имеет (и не только в России) - это еще один способо развода на деньги. Что, многочисленные взломанные банковские системы не имели сертифкатов?

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