[nanomsg] Re: RFC links
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- Date: Wed, 21 Aug 2013 10:55:42 +0200
On 16/08/13 16:18, Paul Colomiets wrote:
This way we allow the functionality but does not hardcode the nanomsg
to a specific implementation of TCPMUX (there is no standard for local
communication with TCPMUX-daemon, right?)
It's not that simple. While fd:// thing solves half of the problem in
nice multiplexer-independent way, there's still the other half, namely
the communication protocol between nanomsg library and the multiplexer
(commands such as "I want to listen for incoming connection for service
XYZ", or "a new connection was established, here's the fd"). This has to
be hardcoded as an additional transport.
Btw, for the sake of discussion, the guys at IETF pointed me to this
document:
http://tools.ietf.org/id/draft-touch-tcp-portnames-00.txt
The change to TCP is not going to happen, but it contains nice summary
of current state of affairs. Also it's unclear why it haven't done for
IPv6 :( BTW, with the IPv6 the port problem does not exists, because
everybody can have any number of ip addresses with single port, right?
I am not an expert on IPv6 but creating new IP addresses to serve as
service names sounds a bit twisted.
Also there is mentioned RPCBIND. As far as I understand it can help us
to build complex projects with multiple services with the
configuration along the lines of:
project: foo
hosts: [10.0.0.1, 10.0.0.2, 10.0.0.3]
That having the service ports for hundreds of internal services
discovered by RPCBIND. Have it ever been considered for nanomsg? Or
does it fall out of scope of the library?
Hm. What's the advantage of using RPCBIND rather than DNS?
Martin
Other related posts:
