[nanomsg] Re: RFC links
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: <nanomsg@xxxxxxxxxxxxx>
- Date: Tue, 13 Aug 2013 09:02:57 +0200
On 2013-08-12 19:13, jimmy frasche wrote:
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?
For reference, here's a C version of a similar service, I've coded it a
long time ago so I don;t remember whether it's fully functional, but it
should give you the idea at least:
https://github.com/sustrik/ve
If we assume the multiplexer is running, how do I, as a process,
register myself with it and specify a protocol?
It's done via UNIX domain sockets. The multiplexer is listening on a
well-known IPC file. Individual applications connect to the IPC address
and send their subscription(s), something like "I would like to receive
all the fds that are aimed for service named XYZ". The multiplexer
remembers the subscription and when a new connection arrives looking for
service XYZ, it takes the fd and passes it to the subscribing process
via SCM_RIGHTS.
You'll of course need some kind of IPC protocol for that, but it's a
single-box thing only, so there's no much point in formalising it.
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?
It should be easy to make the multiplexer listen on multiple ports or
different interfaces (public IP vs. private IP). Additionally, you'll
need to provide a way for the admin to pair services and different
addresses/ports.
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?
Both options are possible. Re-trying to connect makes user's life
easier of course. In that case you also need to re-send the
subscriptions after re-connect succeeds.
Can I register with multiple protocols (seems like that would require
ETSN over domain sockets!)?
Sure, why not. Single process can listen on multiple port. The same way
it could listen on multiple TCPMUX services.
Can I unregister or am I bound until I die?
BSD sockets don't provide a way to un-listen. You have to close the
socket. But it's an API issue, so up to you to decide.
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?
Hope the above helps. Feel free to ask in case of doubt.
Martin
Other related posts:
