[nanomsg] Re: The name service for nanomsg
- From: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Fri, 6 Sep 2013 12:21:42 +0300
Hi Kaspar,
On Fri, Sep 6, 2013 at 11:33 AM, Kaspar Schiess
<kaspar.schiess@xxxxxxxxx> wrote:
>> Some problems to think about:
>>
>> 1. With big clusters it's not realistic to create a record in name
>> service for each box/application/socket. Thus, the name resolution
>> should be rule-based.
>
>
> Doesn't that depend on bind vs. connect? I imagine there's always a way to
> formulate a topology to reduce the number of common names that have to be
> known. Can you give an example where rules are absolutely needed?
>
The example appeared in this thread: A -> B-C -> D (B-C is a device)
How would you distinguish A and C ? If you think one can bind an other
can connect. Consider the following:
A -> B-C -> D-E -> F
If you have better way for resolving this kind of addresses, please describe
>
>> 2. If so, who evaluates the rule? Does name service do that? Or does in
>> only return the rule and socket is responsible for evaluating it itself?
>
> What does the rule depend on? What information is needed for evaluating it?
>
This is outlined in first message of the thread:
hostname app_name topology_id
>
>>> 4. Name service response consists of full a list of nanomsg addresses
>>> to bind/connect to:
>>>
>>> bind: "tcp://127.0.0.1:1234"
>>> connect: "ipc:///var/run/topology.sock"
>>> connect: "tcp://192.168.0.1:2345"
>>
>>
>> Right. Also, socket options could be provided by the name service
>> (priorities, or whatever).
>
> I don't follow that last point. Should name resolution really solve that
> problem? Or should it just solve the problem of turning NAME into a string
> like "tcp://127.0.0.1:1234"? I would be in favour of the latter.
>
Yes. Look at how DNS SRV works. It gives a list of addresses with
priorities and weights.
The decision of bind vs connect is also admin's task not a
programmer's one, so it should be in name service rather than code.
--
Paul
Other related posts:
