（unix domain socket）使用udp发送>=128K的消息会报ENOBUFS的错误

一个困扰我两天的问题，

Google和Baidu没有找到解决方法！

此文为记录这个问题，并给出原因和解决方法。

1、Unix domain socket简介

unix域协议并不是一个实际的协议族，而是在单个主机上执行客户/服务器通信的一种方法，所用API于在不同主机上执行客户/服务器通信所有的API（套接字API，如AF_INET、AF_INET6等类型的API）相同。unix域协议可以视为是进程之间本地通信IPC的一种。

unix域提供两类套接口：字节流套接口（类似TCP）和数据报套接口（类似UDP）。使用Unix域套接口的理由有三：

Unix域套接口往往比位于同一主机的TCP套接口快出一倍。

Unix域套接口可用于在同一主机上的不同进程之间传递描述字。

Unix域套接口把客户的凭证（用户ID和用户组ID）提供给服务器，从而实现能够提供额外的安全检查措施。

Unix域中用域标识客户和服务器的协议地址是普通文件系统中的路径名（类比：IPv4协议的地址由一个32位地址和一个16位端口号构成，IPv6协议的地址由一个128位地址和16位端口号构成。）。

2、问题描述

简单介绍了Unix域套接口之后，进入主题——描述我碰到的问题。由于unix域套接口用于本机间进程通信比网络套接口效率高，因为它是不经过协议栈的！在项目中选择了unix域的数据报套接口。在使用过程中碰到了如下，问题：发送<128K的消息时，客户、进程可以正常收发消息；发送>=128K的消息时，发送端(sendto)返回ENOBUFS的错误。

服务器的代码如下：

代码

。。。。。。
size-131072(DMA)       0      0 131072    1   32 : tunables    8    4    0 : slabdata      0      0      0
size-131072            0      0 131072    1   32 : tunables    8    4    0 : slabdata      0      0      0
size-65536(DMA)        0      0  65536    1   16 : tunables    8    4    0 : slabdata      0      0      0
size-65536             0      0  65536    1   16 : tunables    8    4    0 : slabdata      0      0      0
size-32768(DMA)        0      0  32768    1    8 : tunables    8    4    0 : slabdata      0      0      0
size-32768             0      0  32768    1    8 : tunables    8    4    0 : slabdata      0      0      0
size-16384(DMA)        0      0  16384    1    4 : tunables    8    4    0 : slabdata      0      0      0
size-16384             0      0  16384    1    4 : tunables    8    4    0 : slabdata      0      0      0
size-8192(DMA)         0      0   8192    1    2 : tunables    8    4    0 : slabdata      0      0      0
size-8192              0      0   8192    1    2 : tunables    8    4    0 : slabdata      0      0      0
size-4096(DMA)         0      0   4096    1    1 : tunables   24   12    0 : slabdata      0      0      0
size-4096              4      4   4096    1    1 : tunables   24   12    0 : slabdata      4      4      0
size-2048(DMA)         0      0   2048    2    1 : tunables   24   12    0 : slabdata      0      0      0
size-2048             12     14   2048    2    1 : tunables   24   12    0 : slabdata      7      7      0
size-1024(DMA)         0      0   1024    4    1 : tunables   54   27    0 : slabdata      0      0      0
size-1024             11     12   1024    4    1 : tunables   54   27    0 : slabdata      3      3      0
size-512(DMA)          0      0    512    8    1 : tunables   54   27    0 : slabdata      0      0      0
size-512             208    208    512    8    1 : tunables   54   27    0 : slabdata     26     26      0
size-256(DMA)          0      0    256   15    1 : tunables  120   60    0 : slabdata      0      0      0
size-256              75     75    256   15    1 : tunables  120   60    0 : slabdata      5      5      0
size-192(DMA)          0      0    192   20    1 : tunables  120   60    0 : slabdata      0      0      0
size-192              40     40    192   20    1 : tunables  120   60    0 : slabdata      2      2      0
size-128(DMA)          0      0    128   30    1 : tunables  120   60    0 : slabdata      0      0      0
size-128              86     90    128   30    1 : tunables  120   60    0 : slabdata      3      3      0
size-96(DMA)           0      0     96   40    1 : tunables  120   60    0 : slabdata      0      0      0
size-96              388    400     96   40    1 : tunables  120   60    0 : slabdata     10     10      0
size-64(DMA)           0      0     64   59    1 : tunables  120   60    0 : slabdata      0      0      0
size-32(DMA)           0      0     32  113    1 : tunables  120   60    0 : slabdata      0      0      0
size-64              451    472     64   59    1 : tunables  120   60    0 : slabdata      8      8      0
size-32              871    904     32  113    1 : tunables  120   60    0 : slabdata      8      8      0
。。。。。。

我在Ubuntu 10.10上测试，不会报ENOBUFS的错误。内核版本为：



/proc/slabinfo的信息如下，跟上面的有些差异：



kmalloc的最大限制是8192K，故我们运行上述程序没有问题！
原来都是内核惹得祸阿，害我困惑那么久！！！baidu和google都没有找到原因，因此分享此文，以警惕后者。