On 12/04/2017 19:08, Marlborough, Rick wrote: >>Flipping the direction and failing suggests that one of the hosts may have >>not correctly determined the local network interfaces. >>You can always explicitly set the local interfaces to bind to when creating the socket. >>Later versions in GitHub have corrected some known interface issues with newer RHEL releases and special configurations. >>However because of lack of testing no new official release has been pushed out yet. > > Thanks for responding. My follow on question is, would > this still be the case in light of the following additional information? > > 1. The 2 nodes in question are diskless clients that are spawned > from the same image from the same server. The hardware they are running > on is identical. > > 2. Testing with basic multicast works in both directions.
Yes, it's still worth trying. And setting environments PGM_MIN_LOG_LEVEL=TRACE and PGM_LOG_MASK=0xffff. Under some configurations the exact output interface that gets selected by OpenPGM in the release bundled with 0MQ is a bit unexpected. I had a fair bit of trouble with this myself. It might be worth compiling up some of the OpenPGM example programs (in the OpenPGM source tree) and concentrating on sorting out OpenPGM configuration without 0MQ around. -- Jim Hague - [email protected] Never trust a computer you can't lift. _______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
