![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ОСостроительное. Rich IPC
Вот натеоретизировалось.
IPC надо строить в двух принципиально различных направлениях: "быстрый" IPC - для передачи уже договоренных данных по установленному каналу, и "богатый" - для первичного установления или связи без постоянного канала.
"Быстрый" - на сейчас это традиционные пайпы-сокеты. К средствам "богатого" IPC следует отнести
- выставки (для оповещения о своих способностях)
- очереди (для разовых передач и хэндшейкинга)
- проброс хэндла (для установления канала "быстрого" IPC)
Последовательно с конца:
Проброс хэндла - метод известен - recvmsg()+cmsg в Unix, что-то было в Windows. При этом принимающий процесс должен явно согласиться на приём хэндла; Windows, кажется, это не умеет. Хороший вариант - один процесс запускает что-то типа CatchHandle() в отдельной нити и ждёт приёма.
Очереди - неплохой вариант выглядит так: у процесса может быть несколько очередей обозначенных целыми числами. Очередь 0 предназначена (но не ограничена) для сообщений от системных средств, 1 - для произвольного первичного обмена, 2 и далее - для целей определяемых владельцем. На каждую очередь назначаются права на запись сообщений (acl'ем или хотя бы на уровне owner/group/other), читать может только данный процесс. Процесс определяет предельный размер очереди как сумму размеров сообщений и предельный размер одного сообщения. API процесса-владельца включает: создание/уничтожение; регулирование размера; чтение/удаление сообщений; атомарные чтение и сброс флага случившегося переполнения (попытка записи сообщения при разрешении правами доступа, не состоявшаяся по ограничению размера). API стороннего процесса состоит из одной функции записи (параметры: PID/handle процесса-получателя, номер очереди, адрес и размер сообщения) и возвращает шмогла/почему_не_шмогла.
Сообщение - массив байт (размером например до 64KB). Рекомендованная структура сообщения - в начале два UUID'а (тип и подтип сообщения), дальше в зависимости от этих параметров.
Выставка - набор параметров имя=значение. API процесса-владельца - добавление, удаление, замена, чтение, перебор. API стороннего процесса - поиск процессов с параметрами: только по конкретному имени; по конкретным имени и значению.
Очереди и выставки хранят свои данные в памяти ядра, на что выставляется ограничение ulimit'ами или аналогичными средствами в пределах виртуальной памяти процесса.
IPC надо строить в двух принципиально различных направлениях: "быстрый" IPC - для передачи уже договоренных данных по установленному каналу, и "богатый" - для первичного установления или связи без постоянного канала.
"Быстрый" - на сейчас это традиционные пайпы-сокеты. К средствам "богатого" IPC следует отнести
- выставки (для оповещения о своих способностях)
- очереди (для разовых передач и хэндшейкинга)
- проброс хэндла (для установления канала "быстрого" IPC)
Последовательно с конца:
Проброс хэндла - метод известен - recvmsg()+cmsg в Unix, что-то было в Windows. При этом принимающий процесс должен явно согласиться на приём хэндла; Windows, кажется, это не умеет. Хороший вариант - один процесс запускает что-то типа CatchHandle() в отдельной нити и ждёт приёма.
Очереди - неплохой вариант выглядит так: у процесса может быть несколько очередей обозначенных целыми числами. Очередь 0 предназначена (но не ограничена) для сообщений от системных средств, 1 - для произвольного первичного обмена, 2 и далее - для целей определяемых владельцем. На каждую очередь назначаются права на запись сообщений (acl'ем или хотя бы на уровне owner/group/other), читать может только данный процесс. Процесс определяет предельный размер очереди как сумму размеров сообщений и предельный размер одного сообщения. API процесса-владельца включает: создание/уничтожение; регулирование размера; чтение/удаление сообщений; атомарные чтение и сброс флага случившегося переполнения (попытка записи сообщения при разрешении правами доступа, не состоявшаяся по ограничению размера). API стороннего процесса состоит из одной функции записи (параметры: PID/handle процесса-получателя, номер очереди, адрес и размер сообщения) и возвращает шмогла/почему_не_шмогла.
Сообщение - массив байт (размером например до 64KB). Рекомендованная структура сообщения - в начале два UUID'а (тип и подтип сообщения), дальше в зависимости от этих параметров.
Выставка - набор параметров имя=значение. API процесса-владельца - добавление, удаление, замена, чтение, перебор. API стороннего процесса - поиск процессов с параметрами: только по конкретному имени; по конкретным имени и значению.
Очереди и выставки хранят свои данные в памяти ядра, на что выставляется ограничение ulimit'ами или аналогичными средствами в пределах виртуальной памяти процесса.
no subject
no subject
no subject
Напишите ядерный модуль и распространяйте.