Пакеты по именованному каналу? Однобайтовый буфер или предварительно заданный размер?

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

Ты говоришь:

Учитывая, что я должен предоставить буфер и размер буфера для чтения,

Вы делаете...

и учитывая, что команда чтения блокируется (я полагаю),

Это так, если вы не установите O_NONBLOCK в файловом дескрипторе...

Я либо должен иметь размер буфера, гарантирующий, что я никогда не получу недоработку,

Какие сообщения вы отправляете? С каким размером вы имеете дело? Килобайты, мегабайты, больше?

или узнать размер сообщения заранее.

Нет особых проблем с наличием, скажем, буфера в 4 КБ в ридере и чтением сообщения кусками. Проблема в том, чтобы знать, когда вы дойдете до конца сообщения. Безусловно, для большинства протоколов длина требуется заранее, потому что это упрощает надежное написание кода считывателя.

Если вы собираетесь использовать маркер «конец потока» (EOS), вы выполняете «внутриполосную сигнализацию». И это вызывает проблемы. Какого персонажа вы собираетесь использовать? Что происходит, когда этот символ появляется в данных? Вам нужен механизм выхода, например символ, который означает, что «следующий символ не является маркером EOS». Например, в тексте, связанном с программированием, для этого используется обратная косая черта. На терминале для этой цели часто служит control-V.

Я не хочу, чтобы отправляющая программа знала размер буфера и дополняла его.

Почему отправителю сложно узнать размер буфера? И зачем это нужно "раскладывать"?

Если вы имеете дело с большими объемами данных (скажем, от килобайт и выше), односимвольное решение вряд ли даст приемлемую производительность. Я думаю, вам было бы лучше, если бы отправитель мог определить размер пакета и сообщить об этом читателю, или разработать протокол так, чтобы были ограничения на размер пакета. Если вам нужно передать произвольное количество данных, имейте протокол, в котором говорится:

• Приходит большое количество данных неизвестного общего размера.
• Для каждого подпакета в сообщении говорится: «Это подпакет размером NN КБ».
• Для последнего подпакета размер может быть меньше — это нормально и может означать «конец большого количества данных».
• Если последний подпакет является «полноразмерным», вы можете отправить пустой последний пакет, чтобы указать EOS.
• В качестве альтернативы, если подпакеты могут иметь переменный размер, вы всегда можете отправить явный пакет EOS.

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

Я думаю, что вы должны проектировать свою систему с пакетами, в которых заголовки пакетов включают размер данных (как это делают большинство сетевых протоколов, таких как TCP/IP). И если есть поток данных более высокого уровня неизвестного размера, обработайте его в соответствии с указаниями, изложенными выше. Но даже там лучше, если вы сможете заранее назвать общий размер.

Одним из простых способов было бы иметь дискретный пакет, содержащий ftok (на основе именованного канала) и указатель на строку с завершающим нулем в общей памяти, которая была назначена с использованием возвращаемого значения ftok. Вся остальная дискретная информация может передаваться внутри структуры пакета.

отправитель:

packet.ident = ftok("./mynamedpipe");
packet.pointer = shmget(packet.ident, sizeof(message), IPC_CREAT|IPC_EXCL);
strcpy(packet.pointer, message);

получатель:

message = shmat(packet.ident, NULL, NULL);   

Обратите внимание, что адрес в shmat не указывается явно, чтобы предотвратить перераспределение существующей памяти в процессе получателя.