Атомарная запись в сокет unix?

Трубы

Да, неблокирующая емкость обычно составляет 4 КБ, но для максимальной переносимости вам, вероятно, будет лучше использовать константу PIPE_BUF. Альтернативой является использование неблокирующего ввода-вывода.

Больше информации, чем вы хотите знать, в man 7 pipe.

Сокеты дейтаграмм Unix

Записи с использованием семейства функций send в сокетах дейтаграмм действительно гарантированно будут атомарными. В случае с Linux они также надежны и сохраняют порядок. (из-за чего недавнее введение SOCK_SEQPACKET меня немного сбивает с толку) Много информации об этом в man 7 unix.

Максимальный размер дейтаграммы зависит от сокета. Доступ к нему осуществляется с помощью getsockopt/setsockopt на SO_SNDBUF. В системах Linux он находится в диапазоне от 2048 до wmem_max со значением по умолчанию wmem_default. Например, в моей системе wmem_default = wmem_max = 112640. (вы можете прочитать их в /proc/sys/net/core) Наиболее важная документация по этому поводу находится в man 7 socket вокруг параметра SO_SNDBUF. Я рекомендую вам прочитать его самостоятельно, так как описываемое в нем поведение удвоения емкости поначалу может немного сбивать с толку.

Практические различия между потоком и дейтаграммой

Потоковые сокеты работают только подключенными. В основном это означает, что они могут общаться только с одним партнером за раз. Как потоки, они не гарантируют сохранение «границ сообщений».

Сокеты дейтаграмм отключены. Они могут (теоретически) общаться с несколькими партнерами одновременно. Они сохраняют границы сообщений.

[Я полагаю, что новый SOCK_SEQPACKET находится посередине между: подключением и сохранением границ.]

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

Грубый тест, сравнивающий поток, дейтаграмму и каналы:

# unix stream 0:05.67
socat UNIX-LISTEN:u OPEN:/dev/null &
until [[ -S u ]]; do :;done
time socat OPEN:large-file UNIX-CONNECT:u

# unix datagram 0:05.12
socat UNIX-RECV:u OPEN:/dev/null &
until [[ -S u ]]; do :;done
time socat OPEN:large-file UNIX-SENDTO:u

# pipe 0:05.44
socat PIPE:p,rdonly=1 OPEN:/dev/null &
until [[ -p p ]]; do :;done
time socat OPEN:large-file PIPE:p

Здесь нет ничего статистически значимого. Мое узкое место, вероятно, читает большие файлы.

Скажем, я использую сокет UNIX и записываю x байтов данных от моего клиента. Я уверен, что эти x байтов будут записаны на стороне сервера сокета, когда select() моего сервера взломает?

Если вы используете AF_UNIX SOCK_STREAM сокет, такой гарантии нет, то есть данные, записанные в одном write/send(), могут потребовать более одного read/recv() вызова на принимающей стороне.

По тому же вопросу, будет ли использование SOCK_DGRAM гарантировать, что записи будут атомарными (если такая гарантия возможна), поскольку дейтаграммы должны быть отдельными четко определенными сообщениями?

С другой стороны, AF_UNIX SOCK_DGRAM сокеты необходимы для сохранения границ дейтаграммы и обеспечения надежности. Вы должны получить ошибку EMSGSIZE, если send() не может передать дейтаграмму атомарно. Не уверен, что происходит с write(), поскольку на странице руководства не сказано, что он может сообщать об EMSGSIZE (хотя страницы руководства иногда не перечисляют все возвращенные ошибки). Я бы попробовал переполнить буфер приемника дейтаграммами большого размера, чтобы увидеть, какие именно ошибки сообщают send/write().

Одним из преимуществ использования сокетов UNIX перед трубами является больший размер буфера. Я не помню точно, каков предел буфера ядра канала, но я помню, что его не хватало и я не мог его увеличить (это жестко запрограммированная константа ядра). fast_producer_process | slow_consumer_process был на несколько порядков медленнее, чем fast_producer_process > file && file > slow_consumer_process из-за недостаточного размера буфера канала.