[nanomsg] Re: RFC links
- From: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- To: Martin Sustrik <sustrik@xxxxxxxxxx>
- Date: Wed, 21 Aug 2013 21:25:46 +0300
Hi Martin,
On Wed, Aug 21, 2013 at 2:02 PM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> Is it so? SCM_RIGHTS appears in POSIX standard, so it should be pretty much
> the same on UNIX platforms.
>
Not sure. Quick googling says that even early versions of Mac OS X
haven't it. Don't know about fresh ones. Same with solaris. Don't know
where to get up to date docs.
>
>> 2. There is no industry standard for TCPMUX <-> client protocol
>
>
> Right. Maybe we should draft something ourselves.
>
IMO, it would work well if everybody use same protocol. E.g. if
non-nanomsg service would like to use TCPMUX. Inventing something just
for nanomsg seems doomed.
>> 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.
>
From skimming RFC 2136 it seems that:
1. DNS has single point of failure. You can have slaves for backup,
but you can't update the records in case of failed primary master
2. It doesn't solve the problem of propagating changes to clients
>
>> 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.
>
So DNS resolving in nn_connect() is actually temporary solution?
>
>> 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.
>
There are plenty of situations where consistency is not influenced.
Ones from the top of my head:
1. Add a new node
2. Remove failing node from cluster (its failing anyway)
3. Using idempotent request-reply (some requests will time out, that's ok)
Sure, when changing DNS you must be aware of the consequences, but
make the user restart the whole cluster to update records seems too
much.
--
Paul
Other related posts:
