Надо связать два демона. Первый демон критичный, он передает данные другому демону. При этом при падении второго демона данные не должны пропадать, как и в случае перезагрузки машины (в т.ч. резетом).
Как вариант: FIFO-файл, но ряд ограничений (в первую очередь ограничение размера 4 Кб) заставляет отказаться от этого способа.
Альтернатива - программная реализация FIFO на базе обычного файла...
КАК !?
Или есть другой способ, позволяющий не потерять данные в любой критической ситуации?!
>Надо связать два демона. Первый демон критичный, он передает данные другому демону.
>При этом при падении второго демона данные не должны пропадать, как
>и в случае перезагрузки машины (в т.ч. резетом).Можно поинтересоваться, что за задача?! Биллинг?
>Как вариант: FIFO-файл, но ряд ограничений (в первую очередь ограничение размера 4
>Кб) заставляет отказаться от этого способа.
>Альтернатива - программная реализация FIFO на базе обычного файла...
>КАК !?
>Или есть другой способ, позволяющий не потерять данные в любой критической ситуации?!Может быть стоит обратить внимание на реализации MTA?! В которых сохранность корреспонденции является наиболее критичной задачей. Например, оглянуться на реализацию queue в postfix. У которого очень понятный и лаконичный код. В простейшем случае это могло бы выглядеть так: 1-вый демон, пытается через unix-pipe/tcp отдать данные 2-ому, если от него нет ответа. Он складывает их в очереде, для перманентного хранения на жестком диске, сделав на них fsync. Через некоторое время он пытается обратиться к 2-ому и передать ему данные. В итоге получаем, что даже "при смерти" обоих демонов данные останутся в сохранности и при следующим запуске они смогут совершить корректную транзакцию. Вариаций на тему много...поэтому будет зависеть от Вашей специфики.
>
>Можно поинтересоваться, что за задача?! Биллинг?
>
Так точно!
Хотел использовать что-нить стандартное, но понял, что это все чушь. либо не надежно, либо еще что...
к тому же диплом пишу...>Может быть стоит обратить внимание на реализации MTA?! В которых сохранность корреспонденции
>является наиболее критичной задачей. Например, оглянуться на реализацию queue в postfix.
>У которого очень понятный и лаконичный код. В простейшем случае это
>могло бы выглядеть так: 1-вый демон, пытается через unix-pipe/tcp отдать данные
>2-ому, если от него нет ответа. Он складывает их в очереде,
>для перманентного хранения на жестком диске, сделав на них fsync. Через
>некоторое время он пытается обратиться к 2-ому и передать ему данные.
>В итоге получаем, что даже "при смерти" обоих демонов данные останутся
>в сохранности и при следующим запуске они смогут совершить корректную транзакцию.
>Вариаций на тему много...поэтому будет зависеть от Вашей специфики.
М... хотелось бы подробности, ссылки на инфу.
>>
>>Можно поинтересоваться, что за задача?! Биллинг?
>>
>Так точно!
>Хотел использовать что-нить стандартное, но понял, что это все чушь. либо не
>надежно, либо еще что...
>к тому же диплом пишу...
>
>>Может быть стоит обратить внимание на реализации MTA?! В которых сохранность корреспонденции
>>является наиболее критичной задачей. Например, оглянуться на реализацию queue в postfix.
>>У которого очень понятный и лаконичный код. В простейшем случае это
>>могло бы выглядеть так: 1-вый демон, пытается через unix-pipe/tcp отдать данные
>>2-ому, если от него нет ответа. Он складывает их в очереде,
>>для перманентного хранения на жестком диске, сделав на них fsync. Через
>>некоторое время он пытается обратиться к 2-ому и передать ему данные.
>>В итоге получаем, что даже "при смерти" обоих демонов данные останутся
>>в сохранности и при следующим запуске они смогут совершить корректную транзакцию.
>>Вариаций на тему много...поэтому будет зависеть от Вашей специфики.
>М... хотелось бы подробности, ссылки на инфу.www.postfix.org