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
