As this is a name resolution problem, you’d have to ask yourself what your
overall strategy is. Do you want to support anything else than DNS, ever? How
about service discovery in general, like Bonjour? Or even normal DNS Service
lookups which return a port number in addition to an IP address?
These would need some plug-in system, I guess. So, _if_ you’re going that way
I’d rather integrate the DNS reply filter into that mechanism than creating
prefixes.
Jörn
Von: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx] Im ;
Auftrag von Garrett D'Amore
Gesendet: Donnerstag, 26. April 2018 23:09
An: nanomsg@xxxxxxxxxxxxx
Betreff: [nanomsg] NNG and IPv4 ONLY (or IPv6 only)
Under legacy nanomsg, there is an option “NN_IPV4ONLY” that can be used to
restrict the resolver so that it only resolves names using AF_INET (to IPv4
only). The idea here being to exclude sometimes buggy IPv6 interfaces.
(Interestingly, there is no equivalent NN_IPV6ONLY option.)
I’ve never used this option myself. But I do understand what a pain it is
sometimes dealing with split connectivity between IPv6 and IPv4.
I’m proposing to handle this a different, and IMO more elegant, way in NNG.
What I’d like to do is permit a URL to be specified as:
tcp4://<name>:<port>
or
tcp6://<name>:<port>
in addition to the tcp:// prefix. The *only* difference with these URLs is
that the tcp4 scheme would restrict itself to resolving via AF_INET, and tcp6
would resolve via AF_INET6. tcp:// would resolve as usual via AF_UNSPEC. This
would give applications a lot more control. (Note that it would be possible
to connect from tcp:// to either of these, so there should not be compatibility
concerns, except that legacy nanomsg and mangos don’t know about these new
schemes. I can retrofit them — especially mangos — if there is a need.
The NN_IPV4ONLY option would *not* be supported in NNG. (I would either
silently discard it, or return NNG_ENOTSUP. I can be convinced either about
that one.)
Any strong opinions about any of this?
- Garrett
