[zeromq-dev] RFC: zbeacon for dhcp-style discovery

[Arnaud Loonstra]

On 11/30/2013 06:30 PM, Michael Haberler wrote:
> Hi Arnaud,
>
> Am 30.11.2013 um 17:16 schrieb Arnaud Loonstra <arnaud at sphaero.org>:
>
>> On 11/30/2013 03:49 PM, Michael Haberler wrote:
>>> I have a seemingly trivial problem where I currently have tunnel vision:
>>>
>>> if I send a directed UDP packet to the beacon socket, the s_beacon_recv () callback isnt called except if I force the destination address to broadcast (255.255.255.255; in which case tcpdump does display the packet)
>>>
>>> if I set the sender address to one of the interface addresses, the packet doesnt go out as per tcpdump and s_beacon_recv() isnt called
>>>
>>> I wonder if I stepped into some socket behavior which I overlooked? noecho is not the cause btw.
>>>
>>> - Michael
>>
>> Hi Michael,
>>
>> I just tried it with the python zbeacon and the only way I can send data
>> from socat to the socket is by specifying the broadcast option:
>>
>> $ socat - UDP-DATAGRAM:255.255.255.255:5670,broadcast
>> sdkfjlsfjlsdfjls
>>
>> works okay, I reveive an error in zbeacon because the filter doens't match.
>>
>> $ socat - UDP-DATAGRAM:255.255.255.255:5670
>> sdflsdkf;sfk;slfk;fk;sfk;sd
>> 2013/11/30 17:11:57 socat[31591] E sendto(3, 0x1ad99d0, 28, 0, AF=2
>> 255.255.255.255:5670, 16): Permission denied
>>
>> In netstat I see the socket only listening on the broadcast address:
>> udp        0    768 255.255.255.255:5670    0.0.0.0:*
>>          31430/python3
>
> thanks! this makes perfect sense - my implicit assumption so far was that udpsocket would receive unicasts just as well, which likely was the error - in retrospect there's no good reason it should
>
> this would suggest that binding udpsocket also for each interface address will result in the desired behavior. I'll try that but I'm sure that was it.
>
> is that a change we're willing to accept? I dont see side effects as of now - yet
>
> - Michael


Well I've been thinking about your proposal but I'm not sure to do this 
this through udp. If you just don't broadcast all the time and don't 
expire nodes automatically you have exactly what you need in Zyre. If a 
node broadcasts other nodes can reply through unicast like done now in 
Zyre.

If you don't want Zyre and want to do it zbeacon you would need to open 
an extra socket I guess. You could then also do it outside of zbeacon 
the same way Zyre uses zbeacon now.

But anyways if we want this in zbeacon we need to open an extra socket. 
The only side effect I see is in how we would specify we want this 
behaviour in zbeacon or not? Only a master node would need to listen for 
unicast right?

Rg,

Arnaud
--
w: http://www.sphaero.org
t: http://twitter.com/sphaero
g: http://github.com/sphaero
i: freenode: sphaero_z25