[zeromq-dev] Zyre ipaddress in Hello message

[Arnaud Loonstra]

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 <lindleyf at gmail.com> 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