在unix套接字上写原子吗? [英] Atomic write on an unix socket?

问题描述

我正在尝试在管道和 unix套接字之间进行选择，以实现IPC机制.
都支持select()和epoll()函数，这很棒.

I'm trying to choose between pipes and unix sockets for an IPC mechanism.
Both support the select() and epoll() functions which is great.

现在，管道具有4kB(到目前为止)的原子"写入，这是Linux内核保证的.
Unix套接字是否存在这样的功能?我找不到任何明确说明这一点的文件.

Now, pipes have a 4kB (as of today) "atomic" write, which is guaranteed by the Linux Kernel.
Does such a feature exists in the case of unix sockets? I couldn't find any document stating this explicitely.

说我使用UNIX套接字，并从客户端写入x字节的数据.我确定服务器的select()破解时，这x个字节会写在套接字的服务器端吗?

Say I use a UNIX socket and I write x bytes of data from my client. Am I sure that these x bytes will be written on the server end of the socket when my server's select() cracks?

在同一主题上，使用SOCK_DGRAM是否可以确保写操作是原子的(如果可以做到的话)，因为数据报应该为单个定义明确的消息?
那么，使用SOCK_STREAM作为传输模式有什么区别?

On the same subject, would using SOCK_DGRAM ensure that writes are atomic (if such a guarantee is possible), since datagrams are supposed to be single well-defined messages?
What would then be the difference using SOCK_STREAM as a transfer mode?

谢谢.

推荐答案

管道

是的，非阻塞容量通常为4KB，但是要获得最大的可移植性，最好使用PIPE_BUF常量.一种替代方法是使用非阻塞I/O.

Pipes

Yes the non-blocking capacity is usually 4KB, but for maximum portability you'd probably be better off using the PIPE_BUF constant. An alternative is to use non-blocking I/O.

man 7 pipe中您想了解的更多信息.

More information than you want to know in man 7 pipe.

写入是 atomic 的.对于Linux，它们也很可靠，并且可以保留顺序. (这使我最近对SOCK_SEQPACKET的介绍有些困惑.)man 7 unix中有许多与此有关的信息.

Writes using the send family of functions on datagram sockets are indeed guaranteed to be atomic. In the case of Linux, they're reliable as well, and preserve ordering. (which makes the recent introduction of SOCK_SEQPACKET a bit confusing to me) Much information about this in man 7 unix.

最大数据报大小取决于套接字.使用SO_SNDBUF上的getsockopt/setsockopt访问.在Linux系统上，它的范围在2048和wmem_max之间，默认值为wmem_default.例如，在我的系统上，wmem_default = wmem_max = 112640. (您可以从/proc/sys/net/core中阅读它们)有关此问题的最相关文档位于man 7 socket中围绕SO_SNDBUF选项的位置.我建议您自己阅读，因为它描述的容量增加行为一开始可能会让人感到困惑.

The maximum datagram size is socket-dependent. It's accessed using getsockopt/setsockopt on SO_SNDBUF. On Linux systems, it ranges between 2048 and wmem_max, with a default of wmem_default. For example on my system, wmem_default = wmem_max = 112640. (you can read them from /proc/sys/net/core) Most relevant documentation about this is in man 7 socket around the SO_SNDBUF option. I recommend you read it yourself, as the capacity doubling behavior it describes can be a bit confusing at first.

流套接字只能在已连接的情况下工作.这主要意味着他们一次只能与一个对等方进行通信.作为流，不能保证它们保留消息边界".

Stream sockets only work connected. This mostly means they can only communicate with one peer at a time. As streams, they're not guaranteed to preserve "message boundaries".

数据报套接字已断开连接.他们可以(理论上)一次与多个对等方进行通信.它们保留了消息边界.

Datagram sockets are disconnected. They can (theoretically) communicate with multiple peers at a time. They preserve message boundaries.

[我想新的SOCK_SEQPACKET在连接和边界保留之间.]

[I suppose the new SOCK_SEQPACKET is in between: connected and boundary-preserving.]

在Linux上，两者都是可靠的，并且可以保留消息顺序.如果使用它们来传输流数据，它们的性能往往相似.因此，只需使用与您的流匹配的那个，然后让内核为您处理缓冲即可.

On Linux, both are reliable and preserve message ordering. If you use them to transmit stream data, they tend to perform similarly. So just use the one that matches your flow, and let the kernel handle buffering for you.

比较流，数据报和管道的原始基准测试

Crude benchmark comparing stream, datagram, and pipes:

# 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

这里没有统计学意义.我的瓶颈可能是读取大文件.

Nothing statistically significant here. My bottleneck is likely reading large-file.

这篇关于在unix套接字上写原子吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！