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 <[email protected]> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
