[zeromq-dev] [PATCH] Additional preparation for IPv6 in 3.0
Martin Sustrik
sustrik at 250bpm.com
Sun Jul 17 20:04:14 CEST 2011
On 07/17/2011 07:47 PM, Steven McCoy wrote:
> Two routes available, either "tcp" and "tcp6" like SMTP or "tcp" with
> ZMQ_PREFER_IPV4 and ZMQ_PREFER_IPV6 options like Java. I'm going with
> the latter.
>
> Interesting note that Windows XP does not support IPV6_V6ONLY socket
> option. There is a couple of ways to handle this, I'm leading with
> detecting the Windows version at run time and if less than 6.0 return -1
> on the zmq_setsockopt call.
The problem here is that 0MQ layer as such doesn't deal with specifics
of addressing used by underlying transports.
As far as 0MQ is concerned addresses are just opaque strings (eg.
"eth0:5555") and it's up to transport layer to interpret the string.
So, when we are faced with need for additional info to interpret the
address we can take two different paths:
1. Expose underlying transport options via 0MQ API.
Pros: We already pass some options to the underlying transports
(ZMQ_SNDBUF, ZMQ_MULTICAST_HOPS etc.)
Cons: Need to set the options prior to each connect/bind rather than
making them a part of the address string:
zmq_setsockopt (s, ZMQ_IPV6, TRUE);
zmq_connect (s, "tcp://server001:5555);
zmq_setsockopt (s, ZMQ_IPV6, FALSE);
zmq_connect (s, "tcp://server002:5555);
2. Extend address string format to deal with the additional info:
zmq_connect (s, "tcp://server001.ipv6:5555");
Pros: Less verbose. Clear separation of transport and 0MQ (scalability)
layer.
Cons: More complex address string parsing.
Thoughts anyone?
Martin
More information about the zeromq-dev
mailing list