[nanomsg] Re: The name service for nanomsg
- From: Nico Williams <nico@xxxxxxxxxxxxxxxx>
- To: Martin Sustrik <sustrik@xxxxxxxxxx>
- Date: Mon, 9 Sep 2013 18:31:02 -0500
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... 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'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.
> 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...
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.
Nico
--
Other related posts:
