[nanomsg] Re: RFC links
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Wed, 21 Aug 2013 13:02:50 +0200
On 21/08/13 12:11, Paul Colomiets wrote:
Hi Martin,
On Wed, Aug 21, 2013 at 11:55 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
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.
Yes. But I would say that as long as it's possible to keep it separate
library, it should be left so, because:
1. It's very platform-specific, not only usual Posix/Windows
separation, but each platform is different
Is it so? SCM_RIGHTS appears in POSIX standard, so it should be pretty
much the same on UNIX platforms.
2. There is no industry standard for TCPMUX <-> client protocol
Right. Maybe we should draft something ourselves.
3. The user base is fairly small, and probably consists of only two or
three target platforms (Windows, Linux, Solaris, I doubt others are
used in enterprise), much less that nanomsg currently targets, right?
It would be nice if it worked even on other platforms. People somehow
irrationally like to work through a single port even though they don't
need it.
Speaking of DNS. Do you really aware of anybody using DNS for their
internal naming service? I'm not aware of any tools that can really
handle the dynamic nature of nanomsg-based cluster, I speaking about
the following tasks:
1. Incrementally alter the record. I mean add/remove and IP address
from SRV record. And update that info on the fly
2. Monitor server availability and alter the records as in #1
3. Propagate new DNS records to the clients (seems to be impossible at
the moment at all)
We should check DDNS. I haven't had time to do that yet but it seems it
could cover our needs.
Also current implementation in nanomsg looks like proof of concept
rather than something real because:
1. nn_connect picks single address only. I believe that it should
connect all the records, and set priorities based on DNS SRV priority
(having weights probably ignored at the moment)
Yes. That should be done. I've imagined a layer on top of the existing
functionality.
When opening a socket you would specify topology name, the libary would
check DNS (or a different distributed database) retrieve all the
necessary settings from there and connect the socket to the topology as
appropriate.
The idea is that the programmer simply assumes existence of certain
topologies (addressed by names, say "market-data" or "invoicing") and
that's it. The actual layout of the topology would be defined by admin
via setting up appropriate DNS records.
2. nanomsg doesn't monitor SRV records, so the only way to propagate
DNS record changes is to restart the whole cluster. It should at least
periodically check for the new records.
Ensuring consistency while topology is in state of change is a
non-trivial thing to do IMO.
Martin
Other related posts:
