[nanomsg] Re: RFC links
- From: Alex Elsayed <eternaleye@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 13 Aug 2013 07:43:21 -0700
On Tuesday, August 13, 2013 09:31:59 AM Martin Sustrik wrote:
<snip>
> 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.
Mm, not quite. I see this as being per-service (only for the 'stocks' service)
but for all of the components of that service. Also, I see this as something
that would be used as a gateway to the wider internet - on the intranet, you
don't need to worry so much about ports-through-the-firewall, and this isn't a
broker in the 'one per network' sense - if you used this across everything,
it'd be 'one per host'
> 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)
No, my intent was that this would be allocated a port for the service, and the
components then share that. You'd pick a port for 'stocks' and then this would
mux heartbeat/updates/commands.
> 2. Namespace collisions (exchange names in AMQP, service names in
> TCPMUX)
See above
> 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.
No, TCPMUX forwards TCP, and may carry any TCP protocol. This at least is SP
and only SP. A number of firewalls do try to do deeper inspection - there's an
out-of-tree 'l7filter' patch for iptables, for instance.
> 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.
Okay, that's good to know.
> 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.
This all assumes a central broker, rather than one that's more like a border
checkpoint. Passing through the firewall kinda implies a SPOF anyway, and any
methods of avoiding that apply here as well - anycast, round-robin, yadda
yadda. Since the multiplexer is edge and not center, failover and such works
just as well as any case where you have multiple XFOO/XBAR connected to the
same topology in the same place.
Take another look at what what I suggested as an API - that would give every
host that called nn_bind(..., NN_MULTI) an instance of the broker. My thinking
was along the lines of this internally spawning the device and doing ipc://
between that and the caller. This isn't intended to be some enterprise broker,
it's intended to be at the host level so it has a much smaller portion of
traffic and far less temptation to add silly buffering junk.
Honestly, it could probably *also* be implemented just fine with socket-
passing instead of XREQ/XREP - I wrote my message not knowing if SCM_RIGHTS
had equivalents on other platforms, but the reason I put the
component/topology ID in the protocol header instead of the message header is
for just that kind of possibility.
> 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.
That kind of thing is *why* my intent was for this to work like SP itself -
user-assigned ports, and multiple instances of the multiplexer. That lets
ports have a granularity closer to traditional TCP services, instead of a far
coarser granularity (AMQP & TCPMUX having a single port) or a finer and thus
inconvenient granularity (one port per SP instance) which causes the problems
you are trying to resolve.
By having the multiplexer be treated as an optional component at the edge used
to reduce port allocations rather than a critical one at the center, it really
does act differently than a central broker. If every participant uses it
(which may be done to cut down on the mental port-allocation overhead), it's
one multiplexer per host, not some central failure point of the *network*.
The multiplexer is unnecessary if port allocation is not a problem, because
multiplexing doesn't occur and string naming devolves to case three (which is
why I brought it up earlier).
Other related posts:
