[nanomsg] Re: RFC links
- From: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- To: Martin Sustrik <sustrik@xxxxxxxxxx>
- Date: Wed, 21 Aug 2013 23:13:04 +0300
Hi Martin,
On Wed, Aug 21, 2013 at 10:23 PM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> Alex, Paul,
>
> I just wanted to say that I an not an expert in naming/discovery area so I
> can't really comment on the stuff.
>
Ah, sorry for annoying you. I am trying to discuss issues that I think
I'm aware of :)
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?
--
Paul.
Other related posts:
