LINUX.ORG.RU

Ищу средство IPC


0

0

Доброе утро!

Есть следующая задача: некоторое приложение принимает из сети информацию, которая должна быть обработана несколькими клиентами. Проще говоря, имеет одного производителя и много потребителей. Каждый пакет должен быть обработан всеми клиентами в "приблизительно" реальном времени. Клиенты -- разнородные процессы на одном хосте. Первое, что приходит в голову -- использовать кольцевой буфер в общей память, а также семафоры для синхронизации. Однако, возможен следующий сценарий: один из клиентов заснет и проспит достаточно долго (мы не удерживаем блокировку долго из соображений эффективности) и проспит весь круг -- нужно иметь способ восстановиться из архива (есть также один клиент, который просто архивирует информацию на диск). Средство IPC, имеющее отношение к диску лучше не предлагать (например, вызов внешнего приложения при ротации архива). Может быть будут какие-либо идеи?

Заранее спасибо.


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

rei3er
()

может имеет смысл UDP с broadcast/multycast? пакет снабдить монотонно-возрастающим номером, каждый клиент по нему сам поймёт что проквакал пакет и переспросит.

небольшая заморочка с собственным протоколом, зато решение масштабируется по самое небалуй :)

MKuznetsov ★★★★★
()

ИМХО, раз есть архивирование на диск, то средняя скорость поступления информации в пакетах не может привышать среднюю скорость диска. Может тупо складывать каждый пакет в отдельный файл, а каждое из приложений будет мапить его себе в память. Надеяться, что дисковый кеш есть и достаточно быстр. Клиенты ждут новый файл на inotify или получают сигнал от архиватора...

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

mky ★★★★★
()
Ответ на: комментарий от Valeriy_Onuchin

> > UDP с broadcast/multycast? 

извиняюсь, что зациклился , уж сильн-наболевшее
..испытал на шкуре "learning curve",
если б изначально знал магические фразы, типа:
"mtu discovery", "nagle algorithm", rtp/rtcp protocol,
frames fragmentation + доХ чего 
++  http://www.29west.com/docs/THPM/index.html

... в общем пришлось методом проб и ошибок изобреать свои
"mtu discovery", "nagle algorithm + builtin compression",
"rtp/rtcp protocol", передосылка  NAKs. 
СБ, всё позади ...

В общем, не всё так просто с "UDP с broadcast/multycast" ...

Valeriy_Onuchin ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.