Есть два процесса под 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 тоже не совсем обязательно присутствует.

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

Всех благ!

Сообщение отредактировал psL - Jan 15 2006, 09:45

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

#define MAGIC 0xFEEDBEEF

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

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

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

Сообщение отредактировал Harbour - Jan 14 2006, 19:07

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