[nanomsg] Re: RFC links

  • From: jimmy frasche <soapboxcicero@xxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Mon, 12 Aug 2013 10:13:16 -0700

On Mon, Aug 12, 2013 at 1:19 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> Still, AFAIU it works only inside a single process. What I would like to is
> to have is a daemon that would listen for incoming connections and then pass
> them via UNIX domain socket's SCM_RIGHTS feature to the registered
> *processes*.

Well, sure, it's just a library, but it could be used to make such a program.

I've never written a program like that so it sounds fun. Might give it a go.

What are the semantics of it?

If we assume the multiplexer is running, how do I, as a process,
register myself with it and specify a protocol?
What if I need two such multiplexers (say, one for internet facing and
one for internal only oh-god-don't-let-the-internet-know-about-these,)
how do I know which one to talk to?
What happens if the multiplexer dies or is accidentally killed, do the
registered processes have to watch it and go into a wait loop trying
to find a new multiplexer to register with, just handle current
connections and then die and hope some script in a process supervisor
noticed this and restarted everything somewhere else?
Can I register with multiple protocols (seems like that would require
ETSN over domain sockets!)?
Can I unregister or am I bound until I die?

Even if we assume one process = one protocol and is bound till it
dies, which seems like a nice, reasonable set of simplifications, I'm
unsure of how to handle the other points. Any thoughts?

Other related posts: