[nanomsg] Re: The name service for nanomsg
- From: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sat, 7 Sep 2013 13:32:36 +0300
Hi Alex,
On Sat, Sep 7, 2013 at 1:13 PM, Alex Elsayed <eternaleye@xxxxxxxxx> wrote:
>>
>> But then you must resolve each of the names with DNS SRV, and combine
>> them somehow by weights and priorities.
>>
>> > That solves the ID to locator issue handily.
>> >
>> > Bind vs. connect is a thorny problem, because it's not just a parameter
>> > that can be set unilaterally. It's a role to play in another, lower-layer
>> > distributed algorithm of bind/listen/connect/accept.
>> >
>> > Transitioning from bind to connect (or vice versa) while running is
>> > honestly something I don't think any admin will do without having some
>> > serious wibblies about it, at least in part because while the transition
>> > is running you suddenly have two incompatible topologies sharing a name -
>> > two hosts set to connect() cannot communicate directly, nor can two set
>> > to bind().
>>
>> There is scenario we practice every day. In development setup we bind
>> a single worker to a known port. In production it connects to the
>> device. So it's definitely a admin-level transition.
>
> Oh, I agree it's definitely doable. What I mean is that doing it live via some
> configuration protocol is likely to be unused, while setups like yours (where
> it's an entirely separate setup) will be commonplace. While it is an admin
> thing, it's not likely something you'd do via a configuration protocol in real
> time - it's something you put in a config file on deploying the topology.
>
The whole point is to get rid of addresses from configuration file, so
that configuration doesn't change on topology changes. If you need to
change config anyway there is no reason not to put address there.
>> > I strongly suspect that best practices, even if bind/connect is available
>> > to the admin, would quickly converge on "always deploy a device as bind()
>> > and have the ends connect(). Rolling out another device for failover/load
>> > balancing later is just adding a new DNS record; switching bind() to
>> > connect() on the endpoints is more pain than it's worth."
>>
>> What about two devices in chain?
>
> Mm, good point. The core of it, as I said above, is that these decisions seem
> like they are best made at *topology* deployment time rather than
> *participant* deployment, or even more dynamically than that.
>
Participant deployment = topology change, AFAIU. E.g. if one of the
nodes failed you may need to turn nn_connect socket to nn_bind.
P.S: need to investigate NAPTR records further, to reason about it
--
Paul
Other related posts:
