Передача данных между процессами (("приёмник" может отсутствовать))

[Zeus]

С++.
СтоИт такая задача:
- есть процесс передающий данные - символьные строки.
- есть процесс, который их получает.

Напрашивается fifo, но проблема в том, что процесс-получатель данных может иногда отсутствовать.
А данные терять нельзя (даже если произойдёт перезагрузка операционки).
Т.е. нужно передавать данные через обычный файл (предполагаю использовать файловые потоки):
передатчик открывает файл,
складывает туда данные,
закрывает файл (обязательно?),
дёргает межпроцессный семафор - просыпается приёмник,
открывает файл,
забирает данные,
закрывает файл,
очищает файл (ofstream с флагом O_TRUNC).
Какая-то неуклюжая работа с файлом и не окривеет линух от такого частого открытия-закрытия файла?

И ещё одно "но": пока файл читает "приёмник" в него нельзя писать. А новые данные уже поступили и их нужно куда-то складывать.
Получается нужно два файла - в один пишет передатчик, второй читает приёмник и как-то переключаться между ними семафорами что-ли...

Вот этот момент, а также через чур активная работа с файлами меня смущают.
Прошу совета коллективного разума

[edoc_modnar]

Что мешает одновременно писать в fifo и в лог? Кроме того, даже обычные файлы не спасут от грубой перезагрузки: если работа с диском идет активно, а памяти много, то данные на момент отключения питания вполне могут остаться в дисковом кэше.

[indie]

мб лучше посмотреть в сторону очереди сообщений (ipc-queues) и разделяемой памяти(shared memory)?

[Zeus]

От выключения питания я и не пытаюсь защититься.

Одновременно и в файл и в fifo....
А потом при загрузке операционки этот "приёмник" ещё раз прочитает в файле всё то же, что уже получал в fifo.

мб лучше посмотреть в сторону очереди сообщений (ipc-queues) и разделяемой памяти(shared memory)?

Думал над этим.
Проблема в том, что "передатчик" может вообще один работать. Т.е. никто не гарантирует, что данные, которые он передаёт - кто-то читает.
Они может вообще раз в сутки будут читаться. Или при загрузке операционки.

[edoc_modnar]

Тогда лог можно использовать в самом крайнем случае, в обработчике SIGTERM для отправителя. Соответственно, приемник должен уведомлять отправителя о принятых данных. Пока данные не приняты, они пишутся в спец буфер отправителя. Когда приняты - буфер опустошается. Если данные не приняты и получен SIGTERM - скидываем их в лог.

[Zeus]

Тогда лог можно использовать в самом крайнем случае, в обработчике SIGTERM для отправителя. Соответственно, приемник должен уведомлять отправителя о принятых данных. Пока данные не приняты, они пишутся в спец буфер отправителя. Когда приняты - буфер опустошается. Если данные не приняты и получен SIGTERM - скидываем их в лог.

Ну вот опять эти уведомления, семафоры (данные готовы, данные прочитаны).
А если "получатель" зависнет и не пришлёт сигнал "данные прочитаны".
А если "отправитель" просто упадёт в кору?

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

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

[indie]

От выключения питания я и не пытаюсь защититься.

Одновременно и в файл и в fifo....
А потом при загрузке операционки этот "приёмник" ещё раз прочитает в файле всё то же, что уже получал в fifo.

мб лучше посмотреть в сторону очереди сообщений (ipc-queues) и разделяемой памяти(shared memory)?

Думал над этим.
Проблема в том, что "передатчик" может вообще один работать. Т.е. никто не гарантирует, что данные, которые он передаёт - кто-то читает.
Они может вообще раз в сутки будут читаться. Или при загрузке операционки.

Если никто ничего не читает, то очередь растет и это можно отследить (/proc/sysvipc/msg)
А если очередь переполнится (по каким либо причинам), то положить сообщение в нее не получится.

Вообще данные стоит класть в разделяемую память, а по ipc лишь передовать сообщение что мол данные появились

[Zeus]

Вообще данные стоит класть в разделяемую память, а по ipc лишь передовать сообщение что мол данные появились

А когда процесс(ы) упадут - что станет с данными?

[indie]

Вообще данные стоит класть в разделяемую память, а по ipc лишь передовать сообщение что мол данные появились

А когда процесс(ы) упадут - что станет с данными?

Если при падении не будет вызвана shmctl(<ID>, IPC_RMID, 0), то данные останутся в разделяемой памяти.

http://citforum.proc.ru/programming/unix/svid_ipc_objects/

поскольку тебе нужно не терять данные (даже после перезагрузки), то лучше наверное использовать файлы, что то типа "сообщение - один файл".

[Zeus]

поскольку тебе нужно не терять данные (даже после перезагрузки), то лучше наверное использовать файлы, что то типа "сообщение - один файл".

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

[indie]

поскольку тебе нужно не терять данные (даже после перезагрузки), то лучше наверное использовать файлы, что то типа "сообщение - один файл".

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

Думаю нет. Вообще стоит поэксперементировать.

только что небольшой эксперемент :

Код: Выделить всё

#!/bin/sh

for i in `seq 1 10000`; do
        echo message $i > ./${i}
        rm ./${i}
done

Код: Выделить всё

indie@vendetta-pc 07.06.19 $ time ./script.sh

real    0m12.089s
user    0m6.920s
sys     0m5.088s

вполне нормально, Linux продолжает работать

[Zeus]

А кучка файликов в каталоге - это неплохая идея. Спасибо.
Займусь реализацией, а там посмотрим как будет работать.