[zeromq-dev] Zyre: interface selection and implementation separation

Yu Dongmin miniway at gmail.com
Sun Dec 2 16:44:42 CET 2012


Hello,

Zyre is trying to use the wireless NIC as possible. SIOCGWINAME is used as the last non-loopback interface is not always wireless nic.

please refer, https://github.com/zeromq/zyre/issues/25

As far as I know, when a system that doesn't have proper ioctl option (that's why we have #ifdef blocks) the last non-loopback should be used. Otherwise it might be a bug.

In case when wireless nic is down and wired nic is up, the wired nic might not be used. This must be handled to support such a wire-connected desktop. 


For the repository separation, I don't have any strong preference.

Thanks
Min

On Dec 3, 2012, at 12:02 AM, Victor Perron <victor at iso3103.net> wrote:

> Hello everybody, 
> 
> I have been interested into Zyre lately. 
> 
> I have tested that in a few situations (WLAN/Ethernet - mixed LANs, various architectures, Android phones...) and there is something that I feel a little limiting:
> the current interface selection algorithm looks for the first WLAN interface available and uses that one to send its beacons.
> 
> Still, I do want zyre to be working from my wired devices too - so this is already a little blocking un this case - and also, at a deeper level, the functions (in C) used to identify those interfaces are not always well supported on each target.
> We already know that quite a lot of OSes do not have the getifaddrs/freeifaddrs functions, that can be easily circumvented. 
> 
> But also some Android versions/phones, for instance, do implement SIOCGIWNAME ioctl() call, some don't. 
> In the end, doing this kind of detection limits the portability of Zyre on those devices, and totally prevent wire-base LANs to be compatible (I think it's good if they can !)
> 
> Why not more simply use the latest non-loopback interface that bears an IP address for instance ?
> 
> Also, on a whole different level, I am asking myself why the C and Java implementations of Zyre are in the same repository ?
> It's hard to make all the contributions match at the same time, and I think-maybe I'm wrong- that this will sooner or later lead to two quite different implementations in the same repo, same commit; which is misleading.
> What do you think about a separation ?
> 
> 
> Regards,
> -- 
> Victor
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




More information about the zeromq-dev mailing list