On Tue, May 31, 2016 at 07:22:33PM +0100, Luca Boccassi wrote: > On Tue, 2016-05-31 at 11:06 -0700, Jim Garlick wrote: > > On Tue, May 31, 2016 at 05:47:24PM +0100, Luca Boccassi wrote: > > > On Tue, 2016-05-31 at 08:52 -0700, Jim Garlick wrote: > > > > On Mon, May 30, 2016 at 09:57:00PM +0200, Michal Vyskocil wrote: > > > > > Hi, > > > > > > > > > > Awesome, the fact czmq handles that is good enough for me. Closed the > > > > > request. > > > > > On Mon, 2016-05-30 at 21:14 +0200, Michal Vyskocil wrote: > > > > > > Hi, > > > > > > > > > > > > Ale's thread about Setting privileges on a UNIX socket inspired me > > > > > > to > > > > > > create small patch to libzmq adding automatic systemd socket > > > > > > activation support. > > > > > > https://github.com/zeromq/libzmq/pull/2015 > > > > > > > > > > > > Right now the feature is fairly minimal - limited to ipc transport - > > > > > > and tested manually using malamute broker. I would like to hear any > > > > > > feedback. If you consider it as useful (or want to avoid dependency > > > > > > on > > > > > > the most hated OSS software on the planet ;-)), please say so. > > > > > > > > > > Hi, > > > > > > > > > > That functionality is already implemented for both IPC and TCP > > > > > sockets. > > > > > > > > > > The low level library has the ZMQ_USE_FD socket option to pass a file > > > > > descriptor, and the high level CZMQ has ZSYS_AUTO_USE_FD env var or > > > > > zsys_set_auto_use_fd(1) function to let zmq automatically match > > > > > endpoints to the corresponding sockets managed by systemd. As long as > > > > > the metadata matches (eg: file path for IPC, address + port for TCP), > > > > > it > > > > > will just work out of the box. > > > > > > > > > > Kind regards, > > > > > Luca Boccassi > > > > > > > > Somehow I missed that - sounds useful! > > > > > > > > Is the usual reconnect behavior disabled when this option is present, > > > > or is that what the aforementioned metadata is used for? I couldn't > > > > find the answer in > > > > http://api.zeromq.org/4-2:zmq-setsockopt > > > > > > > > or in the note about reconnect exceptions in > > > > http://api.zeromq.org/4-2:zmq-connect > > > > > > > > Thanks, > > > > > > > > Jim Garlick > > > > > > Hi, > > > > > > This is used only for server-ish sockets - ie, all those that do any > > > sort of bind and you would use with zmq_bind, so it does not affect > > > zmq_connect (or re-connect). > > > > > > I thought about adding it for the connect side too, but IMHO it wouldn't > > > make much sense. The purpose of systemd-managed sockets is to let > > > servers be started only when a client attempts to connect, and to > > > disentangle dependencies between services and allow them to start in > > > parallel at boot, while having systemd manage the FD buffer so that no > > > messages are lost in either scenario. > > > Neither of these would apply for client-ish sockets. > > > > > > But we can of course look into it, do you have a use case where it would > > > be useful to have? > > > > > > Kind regards, > > > Luca Boccassi > > > > Ah, thanks for the clarification. > > > > Well, there are probably other ways to accomplish my use case. > > We have a broker that loads "plugins" as threads communicating with > > the broker over a per-plugin ZMQ_PAIR inproc:// socket. > > We'd like to be able to launch plugins as processes with fork/exec. > > What I had in mind when I heard about ZMQ_USE_FD was something like > > ZMQ_PAIR over file descriptors obtained with socketpair(), one end > > passed to plugin, one end retained by broker. > > > > Having an endpoint that doesn't appear in any namespace simplifies > > life a bit compared to ipc:// or tcp:// - it wouldn't need to be > > protected against unauthorized access for example. > > > > Jim > > The use case sounds interesting, but as you correctly flagged it before, > the issue with the connect is that by design the actual socket might be > closed and reopened by the library, so I'm not sure how it could be made > to work. > > Maybe it's time for a new intraproc:// transport, perhaps using sealed > pipes that were posted on this ML a while ago? > https://dvdhrm.wordpress.com/2014/06/10/memfd_create2/ > > Kind regards, > Luca Boccassi
Interesting! Well if I grok properly, I'm for it. Especially if it could be made to work with ZMQ_PAIR like inproc://. Thanks also to Michal for the private namespace comment. Good idea. Best, Jim _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev