使用 unix 中的套接字对 IPC 中数据大小的最大限制答案

【问题标题】：Maximum limit on size of data in IPC using sockets in unix使用 unix 中的套接字对 IPC 中数据大小的最大限制
【发布时间】：2014-07-25 23:03:49
【问题描述】：

我在 2 个不同进程之间使用 AF_UNIX,SOCK_STREAM 套接字进行 IPC。客户端通过服务器获取并处理的套接字发送数据。客户端写入套接字的每个数据块的大小大约为 13 KB，使用以下命令：

Send Command in client : send(s, txPackDisp, sizeof(float)*PACKET_LENGTH, 0);

但是，当我使用以下命令在服务器上接收数据时：

Receive command in server : recv(s, bfoData, PACKET_LENGTH*sizeof(float),0);

每次收到的数据只是我发送的数据的一部分（最后有很多零，不应该是这样）。

所以我的问题是：

我可以通过 AF_UNIX,SOCK_STREAM 套接字发送的数据大小的最大限制是否有限制（根据我的阅读，我认为没有）
套接字是否在传输时将数据分解成更小的块，如果是这种情况，我需要单独接收更小的块还是像我现在正在做的那样接收单个块。
这里用AF_UNIX,SOCK_DGRAM套接字会更好吗？

P.S : 服务端和客户端的主要功能的源代码可以在这个问题中看到：IPC using Unix Domain Sockets

【问题讨论】：

标签： c sockets unix ipc

【解决方案1】：

Q1) Is there a limit on the maximum limit on the size of data that I can send over the AF_UNIX,SOCK_STREAM socket ( from what I have read , I don't think there is )

你是对的。 SOCK_STREAM 没有真正的限制。

Q2 a) Does the socket break up the data into smaller blocks when transferring

你是对的。流被分成一个可管理大小的数据包，由发送器和接收器协商。

Q2 b) and if thats the case do I need to receive the smaller blocks individually or as single block like I am doing right now.

你不需要做任何事情。流在另一端重新组合，就像它被传输一样。

Q3) Will it be better to use AF_UNIX,SOCK_DGRAM socket here.

没有。 除非您需要了解有关数据包大小协商、检查丢失数据包并重新发送它们、确保正确管理乱序接收的数据包等方面的所有知识。

【讨论】：

【解决方案2】：

对于 SOCK_STREAM 套接字，不保留消息边界。系统可以在远端将消息分割成多条消息。

另一方面，SOCK_DGRAM 套接字总是要么发送整个消息，要么不发送。

请参阅：socket 的 POSIX 规范：

SOCK_STREAM 提供顺序的、可靠的、双向的、连接模式的字节流，并且可以为带外数据提供传输机制。 SOCK_DGRAM 提供数据报，它们是无连接模式、固定最大长度的不可靠消息。

和send:

如果消息太长而无法通过底层协议，send() 将失败，不会传输任何数据。

在 AF_UNIX 的情况下，决定是否可以发送消息的主要决定因素是是否有足够大的连续缓冲区来容纳您的数据。由于您发送的是 13KB，因此这两种方式都不太可能成为问题。

如果您坚持使用 SOCK_STREAM，那么您的接收代码需要为这样一个事实做好准备：一次调用 recv 可能无法检索到发件人发送的整个消息。 recv 将返回实际接收到的字节数，如果有错误则返回 -1。如果消息是固定长度的，那么您可以重复调用它，直到获得完整的消息。

如果您切换到使用 SOCK_DGRAM，那么您可以放心，整个消息将一键发送，但您可以发送的消息大小将受到限制。不过 13KB 应该没问题。

一般来说，SOCK_DGRAM 不保证可靠，也不保证消息按顺序传递。然而，在大多数 unix 实现中，AF_UNIX 数据报是可靠的并且不会被重新排序（参见：man unix。查看手册页以了解您对 'nix 的看法，看看是否适用）。

【讨论】：