[zeromq-dev] 0MQ/2.0-beta1 on OSX

[Asko Kauppi]

Hi again.

I had a look at this OS X PowerPC "issue" today, and it's not really  
an issue at all.

I was using "en0" blindly, without realizing it is wired Ethernet that  
I don't have hooked up on this laptop. Using "en1" (wlan interface)  
works.

<<
$ ./local_lat tcp://en1:5555 1 10000 &
[1] 53797
$ ./remote_lat tcp://192.168.0.12:5555 1 10000
message size: 1 [B]
roundtrip count: 10000
average latency: 87.186 [us]
<<

I got to this only through deepdive debugging, to check the obvious!    
***stupid me***

The trouble I see from your (ZeroMQ's) side is keeping first time  
evaluators on a smooth run. Error messages for not getting the right  
interface would work here - to make it look less like a bug / crash /  
whatever. Something like:

	"Interface 'en0' is not currently available"

And of course the mention you were placing on "eth0" vs. "en0" (on the  
website) should cover "eth1" and "en1". At least.


*** Local looping on OS X:

This is to clarify you how local looping works on OS X. Don't know if  
this is important (maybe for initial evaluators it is):

With "en0" or "en1" I must use the actual IP number. "localhost" or  
127.0.0.1 won't work.

For local looping there's a completely separate interface, "lo0":
<<
$ ./local_lat tcp://lo0:5555 1 10000 &
[2] 53959
$ ./remote_lat tcp://127.0.0.1:5555 1 10000
message size: 1 [B]
roundtrip count: 10000
average latency: 82.377 [us]
<<

-asko



Martin Sustrik kirjoitti 13.1.2010 kello 10:55:

> Asko,
>
>> Running actual tests on OS X PowerPC fails, though:
>> <<
>> $ ./local_lat tcp://en0:5555 1 10000
>> Assertion failed: (rc == 0), function main, file local_lat.c, line  
>> 52.
>> <<
>> 'errno' is 22 (EINVAL), which is not one of the documented values  
>> for  zmq_bind(): http://api.zeromq.org/zmq_bind.3.html
>
> It looks like the NIC name resolving code doesn't work as expected.  
> Check using IP address of the NIC instead of NIC name. If it works,  
> can you possibly debug the NIC name resolving code (ip.cpp:184) and  
> check out why it fails on OSX/ppc?
>
> Thanks.
> Martin