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

Reply via email to