[nanomsg] Re: The name service for nanomsg
- From: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- To: Martin Sustrik <sustrik@xxxxxxxxxx>
- Date: Fri, 6 Sep 2013 11:19:07 +0300
Hi Martin,
On Fri, Sep 6, 2013 at 10:03 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> On 05/09/13 17:57, Paul Colomiets wrote:
>
>> 1. The nanomsg socket should be used for name resolution. I propose to
>> pass the socket through the environment:
>>
>> NN_NAME_SERVICE=tcp://127.0.0.1:1234 ./your_program
>
>
> Pluggable yes, but using nanomsg wire protocol doesn't seem very useful.
>
Why you think so?
> Basically, what you need for name resolution is some kind of [distributed]
> database. Writing such database ourselves is probably waste of effort, given
> there's a wide range of them available.
>
Actually yes and no. We are not going to write that kind of database.
But below, you are talking about the rules for getting addresses. We
are definitely going to invent rule evaluation. So it's somewhere in
the middle of the things.
> However, these databases typically have their own wire protocols which we'll
> have to use. Examples: DNS, MySQL etc.
>
Yes. But we can't just make a transport. We must also do failover,
check for updates, etc. There is also no good asynchronous MySQL
implementations. It's not a problem if name service is separate
process or thread, but it's a problem if we want to embed MySQL client
into nanomsg itself.
>
>> 2. When there is a environment variable the "topology://name"
>> addresses are supported for nn_connect
>
>
> I have a feeling that the name service thing is almost an entire new layer
> on top of the existing API. The evidence:
>
> 1. Single "topology"-style socket can internally use any nn transport (TCP,
> IPC etc.) which seems to suggest that they are not on the same layer.
>
> 2. Standard nn sockets allow for multiple binds and connects.
> "topology"-style sockets allow for only a single connect.
>
> That being said, what about introducing a new address family?
>
> s = nn_socket (AF_SP_TOPOLOGY, NN_REQ);
> nn_connect (s, "dns://mytopology");
>
This is a great idea actually.
>
>> 3. The name request consists of the following parts:
>>
>> <hostname> <app_name> <topology_id>
>>
>> where <hostname> is a gethostname() of requester, <app_name> is a name
>> passed with NN_PROCESS_NAME, and <topology_id> is an argument passed
>> to nn_connect
>
>
> This needs some more thinking. The overall idea is that the endpoint
> identifies itself ("I am X") and name service tells it where to connect etc.
>
> 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.
>
> 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?
>
I think it's definitely a name service. The reason is: we still don't
know how the name service will be used. So we should leave much more
room for experimentation. And we can't model based on DNS, because
that is very old and very limited for our purposes.
>
>> 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).
>
Yes, I forgot the priorities. But what other options you expect? Or
you just saying format should be extensible?
--
Paul
Other related posts:
