[nanomsg] Re: The name service for nanomsg
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Fri, 06 Sep 2013 09:03:13 +0200
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.
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.
However, these databases typically have their own wire protocols which
we'll have to use. Examples: DNS, MySQL etc.
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");
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?
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).
Martin
Other related posts:
