[nanomsg] Re: RFC links
- From: Alex Elsayed <eternaleye@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Wed, 21 Aug 2013 10:53:25 -0700
On Wednesday, August 21, 2013 01:11:49 PM Paul Colomiets wrote:
> Hi Martin,
>
> On Wed, Aug 21, 2013 at 11:55 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
<snip>
> > 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.
RPCBIND is really quite horrid. It allocates the service ports dynamically (so
you have to use portreserve or the like to prevent it from taking something
important which is needed elsewhere) AND adds a roundtrip on connect because
it needs to ask the portmapper service what port the real service is running
on.
> 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?
What I'd see for *local/internal* service listing is using
Avahi/Zeroconf/MDNS. It's based on DNS, but it's sent out by every
participating host. DNS for WAN, Zeroconf for LAN.
For a public service, you'd really want a real DNS name anyway, just like
(say) an MX record.
I agree on nn_connect and SRV priorities.
If this is a local network, then each host is announcing its own services over
Zeroconf, so just reconnecting to that host would fetch the updated record.
Other related posts:
