On 01/01/2014 10:49 PM, Pieter Hintjens wrote: > Yes, that seems like the simplest stupid solution. It would let us > also do IPv4 and IPv6 at the same time, as you say. > > On Wed, Jan 1, 2014 at 7:27 PM, Lindley French <[email protected]> wrote: >> Binding a separate socket to each interface (in fact, binding separately to >> IPv6 and IPv4 addresses) has worked well for me in the past. Then just >> select() on all of them. >> [snip]
>>>> Alternatively, as you say, it could get the originating IP address of >>>> each HELLO message. That is more work. The libzmq API doesn't provide >>>> that directly (we could extract it at authentication time, from >>>> ZMQ/4.0 and later). >>>> >>>> So option 1 then. The flow is, A gets beacon from B, and then connects >>>> to B and sends HELLO. B receives HELLO from A, and connects back to A. >>>> So A knows what address it received a beacon on. >>>> >>>> It seems we need to use recvmsg() instead of recvfrom(). There's an >>>> example here: I'm not sure about the recvmsg call. It's only available in python since version 3.3 http://docs.python.org/3.3/library/socket.html#socket.socket.recvmsg Is it available on other platforms? I've been playing with but I'm not sure it gives the info we need: https://gist.github.com/sphaero/8218025 My output is: Setting up a broadcast beacon on 255.255.255.255:1200 b'hoi\n' 255.255.255.255 192.168.12.224 2 b'hoi\n' 255.255.255.255 192.168.12.224 3 The last number is the interface index. That's the only data usable as the ipaddresses of both packets is the same although it's received on different interfaces. >>>> So then, zbeacon would update its hostname property after each recv, >>>> and the caller could use this to construct an accurate HELLO message. If zbeacon would be updating the ipaddress of itself we could run into a conflicting situation as it is asynchronous. (Where it's ipaddress is set when receiving a beacon while it was just sending a hello to a node on an other interface.) The HELLO message should contain the ipaddress of the interface it is send out from. Hence it's easiest to get that address on the receiving side IP wise... Polling on multiple interface should be done anyways, e.g. ipv6. But how would the solution scale to other transports... a beacon could just as well broadcast other transport possibilities? The beacon now only broadcasts it's port number. But how do we deal with it in situations of mixed ipv4 and ipv6 and possibly others? The essence is that the beacon is announcing a node and inside the beacon it contains the minimal information how one could connect to it. IMHO the easiest way to solve this is to get the ipaddress through the 0mq socket. Pieter you said this was available in 0mq4+. Are there any examples or docs? Rg, Arnaud -- w: http://www.sphaero.org t: http://twitter.com/sphaero g: http://github.com/sphaero i: freenode: sphaero_z25 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
