[nanomsg] Re: RFC links
- From: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- To: Martin Sustrik <sustrik@xxxxxxxxxx>
- Date: Wed, 21 Aug 2013 13:11:49 +0300
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
2. There is no industry standard for TCPMUX <-> client protocol
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?
> I am not an expert on IPv6 but creating new IP addresses to serve as service
> names sounds a bit twisted.
>
Not more twisted than using TCPMUX in my opinion :)
> Hm. What's the advantage of using RPCBIND rather than DNS?
>
I'm not an expert. But probably there is a reason why certain kinds of
software uses rpcbind instead, e.g. networked file systems. It may be
legacy. Anyway, it's easy to keep separate library for that.
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)
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)
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.
What's you vision on these tasks?
--
Paul
Other related posts:
