Hi all,
I've run into a problem specifying an interface to 0MQ for use with PGM.
Deploying across a fleet of machines with differing hardware configurations, I
want to specify the interface by selecting the interface that the hostname IP
resolves to, as this will work in my general case.
Unfortunately, I have some configurations that have more than one IP address
assigned to an interface. To be clear, I don't mean a Linux aliased interface
like eth0:1. I mean
$ ip addr
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
group default qlen 1000
link/ether 00:30:67:9f:51:49 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 33011sec preferred_lft 33011sec
inet 10.169.10.2/24 scope global eth0
valid_lft forever preferred_lft forever
I've run into this on Linux boxes in the test lab, but in particular, this is
used on AIX clusters to assign an internal cluster address (for heartbeats)
and an external node address to the same interface. The internal address is
the first on the interface.
My problem is that 0MQ/PGM will call into PGM to resolve the hostname to an
interface, and then when binding will pass just the interface back to PGM,
which then chooses the first IP address on the interface to bind to. So on the
cluster, the node hostname is found as the second address on the interface,
but my outbound EPGM packets have a sender address of the interface cluster
address, not the node hostname, and are therefore not routable outside the
cluster.
I can't demand the reconfiguration of the boxes, particularly the cluster, so
as I see it I'm going to have to return an interface address index as well as
the interface number from PGM and then pass it back in. This requires mods to
OpenPGM as well as 0MQ - unless I'm missing something?
The OpenPGM page at code.google.com seems closed for business. Where does
OpenPGM reside these days? As you may have inferred, I have some OpenPGM
patches to add AIX support too...
--
Jim Hague - [email protected] Never trust a computer you can't lift.
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
