客户端能否确定服务器是否接受（）了一个 unix 套接字？答案

【问题标题】：Can a client determine whether the server has accept()'d a unix socket?客户端能否确定服务器是否接受（）了一个 unix 套接字？
【发布时间】：2010-04-30 19:02:48
【问题描述】：

我正在处理一个错误的服务器，它有时会无法接受（）连接（但它的监听套接字保持打开状态）。这是在带有 unix 域套接字的 Linux 上。

目前检测到这一点的唯一方法是在发送一堆数据后，缓冲区填满并阻塞，服务器不发送任何回复。这种事后很久的故障模式很难与其他错误区分开来 - 服务器可能由于其他原因而无响应。

特别是对于 unix 域套接字，内核似乎应该知道是否发生了 accept()；有什么办法可以找出来吗？客户端是否可以阻止直到 accept() 以某种方式发生，或者至少检查它是否有？

这只是为了调试目的，所以它可能有点难看。

【问题讨论】：

默认情况下，连接将阻塞，直到连接被接受。不知道我是否理解你的问题
@nc3b：不，connect() 会阻塞，直到连接建立并在侦听积压中挂起。这就是 listen() 调用中的 backlog 参数的全部意义 - 它设置了可以挂起的连接数。

标签： linux sockets network-programming unix

【解决方案1】：

我会说答案是更改协议，以便服务器首先发言（如 SMTP，而不是 HTTP）

内核在 accept() 系统调用之前就已经接受了套接字；如果它永远不会到达，那么套接字就会处于等待状态。无法将此与接受连接但不说话的服务器区分开来。这是 BSD 套接字一直工作的方式。

【讨论】：

是的，很遗憾我无法更改协议或服务器，否则就没有必要这样做了 ;-) 这对解决问题服务器很有用。我不认为有办法做到这一点，但理论上内核确实知道 accept() 是否已经发生 - 在本地 unix 套接字上 - 所以只是询问是否有人知道方法。很明显，在 TCP 情况下这是不可能的

【解决方案2】：

看起来这个问题的答案是“不”；内核无法获取此信息。

（更改协议不是答案，因为我正在调试一个预先存在的不可更改的协议）

【讨论】：