[zeromq-dev] openpgm

Marlborough, Rick RMarlborough at aaccorp.com
Mon Apr 17 15:24:28 CEST 2017

Designation:  Non-Export Controlled Content  

Thanks Jim. Where is the output of this trace going to? Standard out?

-----Original Message-----
From: zeromq-dev [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Jim Hague
Sent: Thursday, April 13, 2017 5:35 AM
To: ZeroMQ development list
Subject: Re: [zeromq-dev] openpgm

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 - jim.hague at acm.org          Never trust a computer you can't
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org


More information about the zeromq-dev mailing list