如何可靠地检测丢弃的网络链接请求或响应答案

【问题标题】：How to reliably detect dropped netlink requests or responses如何可靠地检测丢弃的网络链接请求或响应
【发布时间】：2020-04-10 09:29:22
【问题描述】：

我有兴趣将 netlink 用于简单的应用程序（以高频率读取 cgroup 统计信息）。

man page 警告该协议不可靠，暗示应用程序需要准备好处理丢弃的数据包：

然而，从内核到用户的可靠传输是不可能的任何情况。如果套接字缓冲区，内核无法发送 netlink 消息已满：消息将被丢弃，内核和用户空间进程将不再拥有相同的内核状态视图。它由应用程序来检测何时发生这种情况（通过ENOBUFS recvmsg(2)) 返回的错误并重新同步。

由于我的要求很简单，只要有任何意外发生，我只需销毁套接字并创建一个新套接字就可以了。但是我找不到任何关于我的程序期望值的文档——例如，recvmsg(2) 的 man page 甚至没有提到 ENOBUFS。

为了确保我可以判断来自我的应用程序的请求或来自内核的响应已被丢弃，我需要担心什么，以便我可以重置所有内容并重新开始？对我来说很清楚，每当我从涉及的任何系统调用中收到错误时，我都可以这样做，但是例如，如果我的请求在通往内核的途中被丢弃会发生什么？我永远不会收到回复吗？我是否需要建立一个超时机制，让我只等待很长时间才能得到响应？

【问题讨论】：

标签： linux linux-kernel netlink

【解决方案1】：

我在 Ayuso、Gasca 和 Lefevre 的 Communicating between the kernel and user-space in Linux using Netlink sockets 中发现了以下内容：

如果 Netlink 无法将消息从内核传递到用户空间，recvmsg() 函数将返回 没有可用的缓冲区空间 (ENOBUFS) 错误。因此，用户空间进程知道它正在丢失消息 [...]

另一方面，从用户到内核空间的通信中不会发生缓冲区溢出，因为sendmsg() 将 Netlink 消息同步传递给内核子系统。如果使用阻塞套接字，Netlink 在从用户到内核空间的通信中是完全可靠的，因为内存分配会等待，所以不会耗尽内存。

关于ack，看起来担心它们是可选的：

NLM_F_ACK: 用户空间应用程序请求确认消息内核空间以确保给定的请求已成功执行。如果这未设置标志，内核空间通过sendmsg() 将错误同步报告为errno 值。

所以对于我的简单用例来说，我可以天真地使用sendmsg 和recvmsg，通过重新开始整个事情来对任何错误（EINTR 除外）做出反应，也许还有退避。我猜是因为每个请求我只得到一个响应而且响应很小，只要我一次只有一个请求在进行中，我什至永远不会看到ENOBUFS。

【讨论】：

【解决方案2】：

附带说明一下，我们可以在 /proc/net/netlink 的 Drops 列中看到丢弃的 netlink 数据包。例如：

# cat /proc/net/netlink
sk       Eth Pid    Groups   Rmem     Wmem     Dump     Locks     Drops     Inode
76f0e0ed 0   1966   00080551 0        0        0 2        0        36968
36a83ab1 0   1431   00000001 0        0        0 2        0        30297
d7d5db8e 0   563    00000440 0        0        0 2        0        19572
a10eb5c0 0   795    00000515 704      0        0 2        0        23584
c52bbce9 0   474    00000001 0        0        0 2        0        17511
3c5a89a5 0   989856248 00000001 0        0        0 2        0        31686
051108c1 0   0      00000000 0        0        0 2        0        25
ed401538 0   562    00000440 0        0        0 2        0        19576
38699987 0   469    00000557 0        0        0 2        0        19806
d7bbb203 0   728    00000113 0        0        0 2        0        22988
4d31126f 2   795    40000000 0        0        0 2        0        31092
febb9674 2   2100   00000001 0        0        0 2        0        37904
8c18eb5b 2   728    40000000 0        0        0 2        0        22989
922a7fcf 4   0      00000000 0        0        0 2        0        8681
16cfa740 7   0      00000000 0        0        0 2        0        7680
4e55a095 9   395    00000000 0        0        0 2        0        15142
0b2c5994 9   1      00000000 0        0        0 2        0        10840
94fe571b 9   0      00000000 0        0        0 2        0        7673
a7a1d82c 9   396    00000000 0        0        0 2        0        14484
b6a3f183 10  0      00000000 0        0        0 2        0        7517
1c2dc7e3 11  0      00000000 0        0        0 2        0        640
6dafb596 12  469    00000007 0        0        0 2        0        19810
2fe2c14c 12  3676872482 00000007 0        0        0 2        0        19811
3f245567 12  0      00000000 0        0        0 2        0        8682
0da2ddc4 12  3578344684 00000000 0        0        0 2        0        43683
f9720247 15  489    00000001 0        0        0 2        11       17781
e84b6d30 15  519    00000002 0        0        0 2        0        19071
c7d75154 15  1550   ffffffff 0        0        0 2        0        31970
02c1c3db 15  4070855316 00000001 0        0        0 2        0        10852
e0d7b09a 15  1      00000002 0        0        0 2        0        10821
78649432 15  0      00000000 0        0        0 2        0        30
8182eaf3 15  504    00000002 0        0        0 2        0        22047
40263df1 15  1858   ffffffff 0        0        0 2        0        34001
49283e31 16  0      00000000 0        0        0 2        0        696

【讨论】：