Размер pipe и fifo - есть ли ограничения ?

О каком размере pipe идет речь?

Насколько помню там буфер на 4к.

хреново что такие размеры. я прочитал что при переполнении буфера НЕ гарантируется атомарность - совсем хорошо.

> я прочитал что при переполнении буфера

он никак не может переполниться

> НЕ гарантируется атомарность - совсем хорошо

используйте блокировки

что вы собственно хотели? чтобы атомарность была
при любом размере записи? это означает монопольное
использование.

нет, я прочитал следующее:
"при записи большего числа байтов чем это позволяет канал или FIFO, вызов write(2) блокируется до освобождения требуемого места, при этом атомарность операции не гарантируется."

А поскольку когда именно наступит это насыщение не известно, получается
что использовать pipe/fifo вообще не безопастно, поскольку теряется атомарность :(

Что-то я в тупик зашел.
Предпологалось использовать fifo для активного обмена - при этом важна именно атомарность. Сейчас fifo используется в не блокирующем режиме.

Возможно стоит обеспечивать атомарность с помощью сообщений ?

> вообще не безопастно, поскольку теряется атомарность :(

я еще раз повторяю, используйте синхронизацию, если
нужна атомарность при записи > 4K.

можете также использовать datagram unix sockets.

синхронизацию в виде семафоров ?

> синхронизацию в виде семафоров ?

да любую, какая вам нравится

> А поскольку когда именно наступит это насыщение не известно, получается что использовать pipe/fifo вообще не безопастно, поскольку теряется атомарность :(

Используй свою собственную буферизацию и будет атомарность. Если ты можешь определить кончился твой атомарный пакет или нет, то ты можешь буферизировать его сам..

anonymous (22.07.2004 14:39:11):

> Предпологалось использовать fifo для активного обмена - при этом важна именно атомарность.

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

Хочешь сказать что я могу отбросить начало пришедшего пакета если я вижу что он пришел не полностью ? Действительно принемающая сторона может это детектировать а отправляющая ? Черт пожалуй отправляющая то-же ! Надо попробывать !

>>Под Юнихом, как и в любых сисемах с разделением времени, сие >>невозможно концептуально.
Атомарность ? Как это не возможна ? В книгах пишут что как раз ГАРАНТИРУЕТСЯ. Типа есть сервер у него открыт fifo ему туда одновременно пишут два процесса. Один пишет 12345 а другой 67890. Дык вот пишут что гарантируется что придет 1234567890 или 6789012345 но не как не их перемешанные данные типа 1627384950.

anonymous (22.07.2004 16:52:06):

> Атомарность ? Как это не возможна ? В книгах пишут что как раз ГАРАНТИРУЕТСЯ.

В пределах АТОМА, который, кстати, в Линухе аж 4K.

Если ты пишешь в pipe 2Gb текста, то только однопользовательская система может тебе гарантировать атомарность.

В чем вообще задача: есть сервер и у него куча клиентов. У сервера есть открытый fifo куда клиенты кидают пакеты с сообщением о себе и об отрытых ими пайпах связи. Дальше идет интенсивный обмен данными. Сейчас это сделано так: сервер посылает сообщения клиентам по их пайпам, клиенты посылают сообщения серверу по его fifo. Как я теперь понимаю :) fifo сервера может легко переполнится и сообщения потеряют атомарность. Вероятно я переделаю обмен так что клиенты будут посылать сообщения по открытым ими пайпам, а значит данные не будут перемешиватся. Все равно остается открытым вопрос по аутентификации клиентов на сервере. :(

>>В пределах АТОМА, который, кстати, в Линухе аж 4K.
>>Если ты пишешь в pipe 2Gb текста, то только однопользовательская >>система может тебе гарантировать атомарность.
Вот-вот я именно об этом.

anonymous (*) (22.07.2004 16:48:58):

> Хочешь сказать что я могу отбросить начало пришедшего пакета если я вижу что он пришел не полностью ? Действительно принемающая сторона может это детектировать а отправляющая ? Черт пожалуй отправляющая то-же ! Надо попробывать !

Похоже, ты чего-то не то делаешь! В смысле, так не делают.

Прокинь еще пайпов, кто мешает? А если нельзя (например, stdin/out надо пользовать), то задумайся о синхронизации (семафорами, например).

> Все равно остается открытым вопрос по аутентификации клиентов на сервере. :(

может лучше в таком случае использовать unix socket? сервер его слушает и каждому присоеденившемуся клиенту дается по дескриптору. Затем загоняем все эти дескрипторы в один select. И вопросы по поводу атомарности отпадут.

>Сейчас это сделано так: сервер посылает сообщения клиентам по их пайпам, клиенты посылают сообщения серверу по его fifo.

Хотя в таком случае действительно, что мешает просто добавить каждому клиенту по отдельному пайпу для посылки сообщений серверу?

Да я к этому и пришел (как написал выше) :)
Остается проблемма аутентификации. Вероятно это нужно делать тоже не по fifo. SYS V очередь сообщений вроде не подходит. Вроде POSIX очередь сообещний подходит. Жаль книжки под рукой нет, дома уточню...

Спасибо за советы !

>>Остается проблемма аутентификации.
Если тебя устраивает идентификация -> то есть отличный метод - называется pam.
Если нужна именно аутентификации - kerberos поможет.