[nanomsg] Re: The name service for nanomsg
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: Nico Williams <nico@xxxxxxxxxxxxxxxx>
- Date: Tue, 10 Sep 2013 09:00:42 +0200
Hi Nico,
On Monday, September 9, 2013, Martin Sustrik wrote:
On 09/09/13 00:58, Nico Williams wrote:
The degree of automation that can be obtained could be quite
high: all
that's needed is to be able to determine how to join the group given
its URI/address (in either pub, sub, and/or router roles), and
how to
authenticate and authorize membership. The hard part is the latter.
Well, having higher-layer topologies match lower layer topologies is
also non-trivial, but if you manage to automatically match
lower-layer
topology automatically then the only administration problems left
relate to authentication and authorization.
I think the two problems should be attacked separately. For
authentication and authorization the easiest thing to do as first is
nothing. As for matching network topology, I'm not sure what to
suggest. One possibility would be to have a binding to IP
multicast:
leave it to IP and IGMP, but this can't be the only option. Maybe
querying BGP/IGP route reflectors?
Think of the most simple scenario. In your datacenter, you have
components A,B,C,D. As the deployer of the application you want to
specify that A should connect to B and C should connect to D.
What's the automated way to do that? How would you, say, prevent C
connecting to B?
I'd rather ask (and answer) what is A's role, B's role...
Ok, let's say A and C have the same role. So do B and D. What now?
Someone has to decide how should the components connect each to another.
If an
instance comes up wanting to publish, say, NYSE market data, then i
might care first and foremost about whether that instance is authorized
to do this. I might allow any subscribers, and I might allow any
routers in addition to a small number of configured gatekeepers. The
topology should be automatically laid out as much as possible.
I see that some are scared of complexity, but the complexity must be
there no matter what, the only question is: who shoulders the burden?
I agree. The complexity of configuration management is there anyway.
There are only two ways to solve it. Either it's done by programmer by
hand or it is supplied by nanomsg. See my latest blog post.
http://250bpm.com/blog:26
I'll be perfectly happy with what you propose though: make this piece
pluggable. Then those who need security and are willing to write a
plugin... get to.
No problem in making it pluggable, but I feel the security doesn't fit
in here. What exactly would you secure inside configuration management
system? Configuration info?
I believe the security belongs mostly to the core nanomsg/networking
stack and only to much lesser degree to the configuration management.
There's no other way, you just have to specify the rules manually.
And the topic of this thread is how to enable and simplify such
manual configuration.
The Internet runs on automatic, dynamic routing. Much too dynamic even
(I'm referring to attacks on BGP, and proposals based on signed
attestations that amount to writing down parts of the topology as
rules) but certainly enough to prove the point. Multicast and IGMP
prove it further. I'm not saying manual configuration is bad, mind you,
just that it should be possible to make the topology a bit more dynamic
than having to write it down exactly. There's a limit to how much can
be accomplished here, of course, given that pub/sub routers won't likely
be running on IP routers...
We are now talking about equivalent of setting up the infrastructure.
Even with Internet there are people who have to plug the cables in.
Once it's set up, the routing within it is dynamic. Same applies to SP
topologies (think of subscriptions in pub/sub topologies or
load-balancing in req/rep topologies).
You mentioned a console view showing what's up and what's down. But I
might want redundant publishers and i might only care about a topic
having no publishers, as opposed to caring about which instances are up
and which are down. I'd also care about stranded islands of routers and
subscribers, but that's the same thing: from their point of view some
topics have no publishers. Then what I want is to configure topics,
publishers, and gatekeepers, and let the rest be automated.
I think we are on the same line here. As noted above, you set up the
topology manually in the first step and the rely on automatic routing
within the topology.
Martin
Other related posts:
