Posix IPC vs SystemV IPC.

пардон, каких сообщений? message queues что-ли? в таком случае, большинство приложений их просто не использует ни в том ни в другом варианте.

// wbr

Именно Message Queues:) Я имел в виду приложения, которые в принципе используют MQ. Тогда вопрос: почему их не использовать? И в чём их недостаток?

> Именно Message Queues:) Я имел в виду приложения, которые в принципе используют MQ. Тогда вопрос: почему их не использовать? И в чём их недостаток?

а зачем их собственно использовать и в чем их достоинство?

// wbr

D-Bus

Использоваться будет в embedded, с требованиями к минимальному размеру приложения и максимальной надёжностью.D-bus, во-первых жирный, а во-вторых нет на него стандарта, там постоянно что-то меняют. К тому же интерфейс на C не очень удобный. Процессы, между которыми нужно организовать общения, будут компилироваться в одной и той же среде, написано всё будет на С, поэтому проблем не будет ни с порядком байтов, ни с типами. Преимуществ в d-bus не вижу.

Можно конечно через named pipe, или через mmap-нутый файл, но для того и другого придётся писать больше кода, то есть вручную реализовывать передачу сообщений.

> Можно конечно через named pipe, или через mmap-нутый файл, но для того и другого придётся писать больше кода, то есть вручную реализовывать передачу сообщений.

а чем не устраивают обычные Unix Domain Sockets?

// wbr

Из преимуществ d-bus есть только новизна и модность:) Ну и для многих языков есть биндинги, что в моей задаче просто не нужно.

Для них тоже нужно реализовать передачу сообщений. К тому же там нет понятия приоритета сообщения.

> Для них тоже нужно реализовать передачу сообщений.

ну это как раз прямо скажем не сложно. зато в отличии от очередей сообщений можно передавать сообщения произвольного размера.

> К тому же там нет понятия приоритета сообщения.

а оно нужно?

// wbr

Во-первых, сообщения будут небольшого размера. Потом, допустим сервер упал, данные в сокет будет невозможно записать, то есть клиент должен у себя их сохранять. Это усложняет клиент, что не есть хорошо, ибо клиенты в основном будут управлять железом.

Правда под линуксом приоритет в Posix MQ не правильно работает. Хотя порядок правильный, FIFO.

> Во-первых, сообщения будут небольшого размера.

ну допустим. хотя как водится, все течет, все меняется.

> Потом, допустим сервер упал, данные в сокет будет невозможно записать, то есть клиент должен у себя их сохранять.

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

впрочем, попробуйте какие проблемы, это не сложно.

> Это усложняет клиент, что не есть хорошо, ибо клиенты в основном будут управлять железом.

да хоть атомной станцией - это роли не играет :)

// wbr

Потоки использовать не хочется, потому что есть мало опыта в создании многопоточных приложениях и сложность их отладки. Клиент получается слишком большим, разработка его должна быть наиболее простой. Так в чём недостаток MQ? Максимальный размер очереди и размер сообщения не критичен. Если уж понадобиться передать много данных, то тогда открыть тот же пайп или сокет.

> Потоки использовать не хочется, потому что есть мало опыта в создании многопоточных приложениях и сложность их отладки. Клиент получается слишком большим, разработка его должна быть наиболее простой. Так в чём недостаток MQ? Максимальный размер очереди и размер сообщения не критичен. Если уж понадобиться передать много данных, то тогда открыть тот же пайп или сокет.

да по большому счету ни в чем. просто есть более универсальные и распространенные IPC, только и всего.

// wbr

Идея, у d-bus, хорошая, но нафига было его типиизировать, вот что я понять не могу.

пережиток corba:)

> есть более универсальные и распространенные IPC, только и всего.

Вроде бы очереди/семафоры/разд.память везде есть и лежат в основе более навороченых решений - т.е. они же и наиболее универсальны?

> Вроде бы очереди/семафоры/разд.память везде есть и лежат в основе более навороченых решений - т.е. они же и наиболее универсальны?

спорный вопрос. очереди, семафоры и разд. память есть не везде или же не в полном объёме/со своей спецификой. в то время как UDS сокеты или же TCP/loopback - как пример - есть действительно практически везде [последний хоть в Win32].

например, в NetBSD нет именованных семафоров [может уже есть?], в Linux не так давно то-же чего-то не было etc.

// wbr

А для чего тогда POSIX? Тут дело такое, если система не поддерживает POSIX, это уже проблемы системы, и её использовать тогда не предполагается. Сокеты для моей задачи не подходят.

> А для чего тогда POSIX?

POSIX? да в сущности ни для чего. хочешь - следуй, не хочешь - не следуй. хочешь - что-то промежуточное [как правило]. никто ведь не насилует и на сертификацию соответствия пинками не гонит.

> Тут дело такое, если система не поддерживает POSIX, это уже проблемы системы, и её использовать тогда не предполагается. Сокеты для моей задачи не подходят.

да бога ради, это уже сугубо ваши проблемы и проблемы вашего выбора, без вопросов :)

// wbr

То есть никаких проблем в реализации Posix MQ нет. И недостаток только один: их мало кто использует, предпочитают сокеты.

Гм. А может лучше было бы сделать не типизированный сразу? Ибо проще это, и из шела в разы проще было бы сообщения слать, не то что сейчас.

У сокетов есть один плюс -- просто разнести процессы на разные машины и датацентры, что в случае MQ затруднительно.

Это не понадобится:) Типизация нужно в многоязыковой среде, чтобы было понятно, что пришло, и когда не сразу известно, во время compile-time, структура сообщений. То есть для десктопа d-bus очень хорош, для системы со 130Мгц процом и 8-ми мегабайтами флеша как-то не очень:) Поэтому вопрос о дата-центрах тут не уместен, разве что из тысячи таких девайсов сделать кластер:)

Я бы написал свою обертку над чем-то из этого (Скорее всего systemV, т. к. это стандарт де факто). А если понадобится перейти на POSIX, Win32, ... никаких проблем не будет, более того, не будет проблем даже при переходе на сокеты, а написать надо 3-4 функции.

ну понятно, что будет работать через обёртки, чтобы можно было поменять, если что:) Пока что я думаю, как первую версию делать, на Posix IPC или SystemV IPC.

POSIX IPC примитивы автоматически удаляются после умирания последнего процесса-пользователя.

SV IPC примитивы требуют явного удаления и могут оставаться в системе даже если ни одного процесса-пользователя уже нет. Хорошо это или плохо - вопрос отдельный, но "залипание" и необходимость аккуратного удалений/пересоздания SV IPC примитивов после падения программы - известная проблема.

Читайте Стивенса! У него чёрным по белому написано, что у Posix MQ время жизни ядра, то есть, если даже нет процессов, которые открыли очередь, то она не должна удаляться. Fifo и сокеты - наоборот, живут только когда живёт процесс. Posix IPC и SV IPC отличаются в основном названиями функций, и идентификаторами объектов.

Вот именно, читайте. До mq_unlink() уже дочитал? В SV это придётся делать самому.

> У него чёрным по белому написано, что у Posix MQ время жизни ядра, то есть, если даже нет процессов, которые открыли очередь, то она не должна удаляться.

если посмотреть в ядро Linux то можно легко заметить, что очередь сообщений POSIX - это объект файловой системы. со всеми вытекающими...

> Fifo и сокеты - наоборот, живут только когда живёт процесс.

может pipe а не fifo? и какие именно сокеты? UDS, к примеру, могут жить существенно дольше, чем породивший их процесс..

> Читайте Стивенса!

хорошее пожелание. не помешает :)

// wbr

А вы понимаете отличие между __ЗАКРЫТИЕМ__ файла и его __УДАЛЕНИЕМ__? mq_close и mq_unlink - РАЗНЫЕ функции. Далее, я имел в виду именованные каналы - FIFO, неименованные каналы, и сокеты, не важно какие - при записи в них, когда нет читателя, что происходит? Правильно - SIGPIPE. То есть данные туда можно писать только когда есть читатель.

>> У него чёрным по белому написано, что у Posix MQ время жизни ядра, то есть, если даже нет процессов, которые открыли очередь, то она не должна удаляться.

> если посмотреть в ядро Linux то можно легко заметить, что очередь сообщений POSIX - это объект файловой системы. со всеми вытекающими...

который, впрочем, располагается на отдельной mqueue fs -> при перезагрузке созданные очереди, очевидно, будут потеряны и время жизни ядра будет соблюдено.

// wbr

Я имел в виду информацию, которая храниться в IPC объекте. Так же нельзя прочитать данные из сокета/канала если нет писателя, для MQ - это можно сделать.

>который, впрочем, располагается на отдельной mqueue fs -> при перезагрузке созданные очереди, очевидно, будут потеряны и время жизни ядра будет соблюдено.

О чём Стивенс и говорит...

Возможно, я не правильно выразился, под временем жизни, я имел в виду время жизни информации.

> А вы понимаете отличие между __ЗАКРЫТИЕМ__ файла и его __УДАЛЕНИЕМ__? mq_close и mq_unlink - РАЗНЫЕ функции.

Почитай ман про mq_unlink.

> Далее, я имел в виду именованные каналы - FIFO, неименованные каналы, и сокеты, не важно какие - при записи в них, когда нет читателя, что происходит? Правильно - SIGPIPE. То есть данные туда можно писать только когда есть читатель.

Это к времени жизни объекта никакого отношения не имеет.

какой толк от объекта, который существует, если им пользоваться нельзя? Чисто для галочки?

Тут важно понять, под чем понимать "объект IPC". Если в объём понятия "объект IPC" входит его название либо идентифиактор и функции, при помощи которых им можно управлять, то тот же fifo прекращает своё существование как только изчезает процесс-писатель, так как при выполнении функции чтения будет ошибка.