[nanomsg] Re: RFC links
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- Date: Thu, 22 Aug 2013 08:37:18 +0200
On 21/08/13 22:13, Paul Colomiets wrote:
Ah, sorry for annoying you. I am trying to discuss issues that I think
I'm aware of :)
Yes, please do. I'm just saying that I cannot comment on your thoughts
much as I have little experience in the area.
Your description is great. With this description in mind we could
reiterate the approach of having an API defined for name resolution.
What I mean is something along the lines of:
name_request_s = nn_socket(AF_SP, NN_REQ)
# a well known address for the name resolution
# this is similar to specifying DNS server addresses in resolv.conf
name_request_s.connect('tcp://10.0.0.1:7777')
name_change_s = nn_socket(AF_SP, NN_SUB)
# a well known address for the change propagation messages
name_change_s.connect('tcp://10.0.0.1:7778')
# This is a real application socket
socket = nn_socket(AF_SP, NN_SUB)
socket.setsockopt(NN_SOL_SOCKET, NN_NAME_SERVICE, name_request_s)
socket.setsockopt(NN_SOL_SOCKET, NN_NAME_CHANGE, name_change_s)
# The following name `hello_world` will be first
# subscribed for in name_change_s
# (so we don't loose any changes in between)
# Then it will be asked for in name_request_s
socket.connect('tcp://hello_world')
Some minimal service of translating nanomsg name requests to DNS
queries may be implemented out of the box, but this approach leaves
plenty of space for improvement and innovation. Thoughts?
I was thinking of something simpler, like:
s = nn_socket (AF_SP, NN_SUB);
nn_connect (s, "topology://market-data");
The idea being that access to DNS is already configured on the box, so
there's no need to specify additional name-resolution-related properties.
Martin
Other related posts:
