ZeroMQ:检查是否有人在 Unix 域套接字后面监听
上下文:Linux (Ubuntu)、C、ZeroMQ
我有一个服务器,它侦听 ipc://
SUB ZeroMQ 套接字(物理上是一个 Unix 域套接字)。
我有一个客户端,它应该连接到套接字,发布其消息并断开连接。
问题:如果服务器被终止(或以其他方式非自然地终止),套接字文件将保持在原位。如果客户端尝试连接到这个过时的套接字,它会在 zmq_term()
中阻塞。
如果服务器不存在,我需要防止客户端阻塞,但如果服务器处于活动状态但繁忙,则保证交付。
假设我无法通过某些外部魔法(例如通过检查 PID 文件)来跟踪服务器生命周期。
有什么提示吗?
Context: Linux (Ubuntu), C, ZeroMQ
I have a server which listens on ipc://
SUB ZeroMQ socket (which physically is a Unix domain socket).
I have a client which should connect to the socket, publish its message and disconnect.
The problem: If server is killed (or otherwise dies unnaturally), socket file stays in place. If client attempts to connect to this stale socket, it blocks in zmq_term()
.
I need to prevent client from blocking if server is not there, but guarantee delivery if server is alive but busy.
Assume that I can not track server lifetime by some external magic (e.g. by checking a PID file).
Any hints?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
不可移植的解决方案似乎是读取
/proc/net/unix
并在那里搜索套接字名称。Non-portable solution seems to be to read
/proc/net/unix
and search there for a socket name.如果不显示您的代码,所有这些都是猜测...也就是说...
如果您有 PUB/SUB 对,PUB 将徘徊以确保其消息通过。也许您没有使用正确类型的 zmq 对。听起来更像是你有一个 REP/REQ 对。
这样,一旦您从客户端(REQ 端)连接,您就可以执行
zmq_poll
来确定套接字是否可用于写入。如果是,则继续写入,否则关闭客户端并处理错误情况(如果是系统中的错误)。Without showing your code all of this is guesswork... that said...
If you have a PUB/SUB pair, the PUB will hang around to make sure that its message gets through. Perhaps you're not using the right type of zmq pair. Sounds more like you have a REP/REQ pair instead.
This way, once you connect from the client (the REQ side), you can do a
zmq_poll
to determine if the socket is available for writing. If yes, then go ahead with your write, otherwise shutdown the client and handle the error condition (if it is an error in your system).还有另一种解决方案。不要使用 ipc:// 套接字。相反,请使用 tcp://127.0.0.101:10001 之类的内容。在大多数 UNIX 上,几乎与 IPC 一样快,因为操作系统识别出它是本地连接并简化了完整的 IP 堆栈处理。
There is another solution. Don't use ipc:// sockets. Instead use something like tcp://127.0.0.101:10001. On most UNIXes that will be almost as fast as IPC because the OS recognizes that it is a local connection and shortcuts the full IP stack processing.
也许您可以先尝试使用您自己的本机套接字连接到套接字。如果连接成功,您的发布商很有可能可以正常工作。
Maybe you can try to connect to the socket first, with your own native socket. If the connection succeeds, it's quite high possibility your publisher could work fine.