等待 Unix 域套接字被绑定
我正在编写一个客户端应用程序，它通过 Unix 域套接字连接到服务器进程。如果服务器进程未运行，我希望客户端等待，直到服务器启动并侦听套接字上的连接。
目前，我在客户端中有一个重试循环，它每秒调用 connect() 直到成功连接到套接字。
有没有我可以调用的函数，它会简单地阻塞，直到创建特定的命名套接字（例如“/var/mysock”）并将其绑定到服务器进程？
I am writing a client app which connects to a server process through a Unix domain socket. If the server process is not running, I want the client to wait until the server has started and is listening for connections on the socket.
Currently I have a retry loop in the client which calls connect() every second until it successfully connects to the socket.
Is there any function I can call which will simply block until a particular named socket (e.g. "/var/mysock") is created and bound to a server process?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不是完整的答案，但是...
如果您使用的是 Linux，
inotify界面将让您捕获操作的前几个有用步骤：unlink'ing剩余的旧套接字将在其上触发IN_DELETE_SELF。bind'ing 将在父目录上触发IN_CREATE。不幸的是，服务器在
监听之前无法连接。尽管这是下一个合乎逻辑的步骤，但实际上并不能保证它会立即执行。看起来inotify并没有提供一个接口。Not a full answer, but...
If you're on Linux, the
inotifyinterface will let you trap a the first few useful steps of the operation:unlink'ing a leftover former socket will trigger anIN_DELETE_SELFon it.bind'ing will trigger anIN_CREATEon the parent directory.Unfortunately, the server isn't
connect'able until itlisten's. Though this is the next logical step, there's really no guarantee it will do so right away. It doesn't look as thoughinotifyprovides an interface to that.我知道这是一个非常古老的问题，但这可能会帮助通过 Google 到达这里并遇到同样问题的新人。
如果可移植性是一个问题，并且作为指导原则它始终应该如此，那么您这样做的方式是完全正确的。有时，显而易见的解决方案也是正确的。如果您担心如此频繁地尝试
connect()的开销，请在 try 循环中对套接字执行stat()，如果有效，请验证它实际上是一个使用来自stat.h的S_ISSOCK()宏的套接字。只有当所有这些都成立时，您才会尝试connect()。您需要担心奇特的异步通知的唯一时间是客户端应用程序在等待服务器启动时是否可以或应该执行其他工作。这并不典型，但我可以想象您可能想要这样做的情况。在这种情况下，我只需在单独的线程中进行连接尝试。如果您认为合适的话，我可以讨论这里的细微差别，但我认为这对于简单的“等待服务器启动”类型的循环来说有点过分了。
I know this is a very old question but this may help newcomers who arrive here via Google with the same problem.
If portability is a concern, and as a guiding principle it always should be, then the way you are doing it is entirely correct. Sometimes the obvious solution is also the correct one. If you are concerned about the overhead of attempting a
connect()so frequently, in your try loop instead do astat()on the socket and if that works, verify it really is a socket using theS_ISSOCK()macro that comes fromstat.h. Only once all that is true do you try theconnect().The only time you would need to worry about fancy asynchronous notifications is if the client application can or should be doing other work while it waits for the server to start. This is not typical but I can envision cases where you may want to do that. In this case I would simply have the connection attempt in a separate thread. There are nuances here that I can go into if you feel it would be appropriate but I think it's overkill for a simple "wait for the server to come alive" type loop.