[nanomsg] Re: RFC links
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: <nanomsg@xxxxxxxxxxxxx>
- Date: Tue, 13 Aug 2013 09:31:59 +0200
On 2013-08-12 19:17, Alex Elsayed wrote:
So, the question is: Can we draw a line between new service as "new
functionality, completely independent from anything running on the
machine so far" and new service as "new communication channel for an
existing application"?
The first thing you're trying to solve is "I have a service with
multiple
components, and want the components to be on the same port." This is
something
I think should be done at the SP level, by including a component
identifier in
the SP protocol header/handshake.
The second is "I want the components to be identified by string names,
not
port numbers." The above applies, just make the component identifier a
string.
The third is "I want to identify the *service itself* as a string,
too." I
think this should be solved by DNS SRV.
Ok. The third one is out of scope of this discussion. I leave it at
that and won't discuss it further (you may open a separate discussion
thread if you are interested in the problem).
The second one (int vs. string) is an implementation detail. I guess
there's no much to talk about there.
So, we are left with the first one.
As far as solving it in the SP layer, there's a perfect way to do that
-
XFOO/XBAR devices are *already* designed to be transparent. Have it so
that
when nn_bind is called with NN_MULTI, and the nn_socket has a
topology/component identifier string set (nn_setsockopt?), then a
multiplexer
is spawned (on first bind) or negotiated with (for the others). The
multiplexer instantiates the appropriate XFOO/XBAR device, and passes
messages
on appropriately.
That way, you still have one port per service, you have the components
of that
service all there, you don't need to do (non-portable) socket
handoffs, you
aren't using a global namespace (IANA port 1) for something that's
really
service-namespaced (component names - if you have multiple *actual*
services
using the same nanomsg-based protocol, tcpmux gets ugly because
helloooo
namespace collisions), you aren't letting arbitrary TCP traffic pass
through
(which is something that could give any security-conscious admin
hives)...
I think that's a much cleaner solution; it even has the side benefit
that it
works for WHATEVER transports SP may get in the future. You may have
only
defined the TCP binding so far, but when that changes you don't want
to have
built a lot of TCP-assumptions into other layers.
You are basically advocating the classic message broker design (as in
RabbitMQ, MQ series etc.) Message broker is a component that serves as a
hub of all the communication, forwarding the messages to individual
services as required.
There's nothing bad about that per se, but ZeroMQ's and now nanomsg's
mission is to get rid of this kind of centralised design.
That being said, message broker has the same problems as TCPMUX-style
multiplexer:
1. It's using global namespace (5672 for AMQP, 1 for TCPMUX)
2. Namespace collisions (exchange names in AMQP, service names in
TCPMUX)
3. Arbitrary TCP traffic passes through anyway, the only difference is
whether it goes to AMQP broker first, just to get forwarded to the
application, or directly to the application.
The concern about portability of SCM_RIGHTS is a valid one though.
However, AFAICS every system (even Windows!) have some way to do that,
so we should be OK.
In short, broker and multiplexer and functionally equivalent. The only
difference is that broker is more complex, thus more brittle and also a
bigger maintenance liability, it's a serious performance bottleneck etc.
My feeling is that using a message broker would be more of a security
theater. In reality it allows any services inside the network to be
accessed from outside without appropriate approval. However, given that
dev are going to present it to the admin like "we only want you to open
one TCP to let us use ActiveMQ", the admin would get impression that
only *one* service is open to the outer world, would sleep better in the
night and won't bother the devs too much about it.
Martin
Other related posts:
