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

[Michael Haberler]

Arnaud,

got to work on this again -

yes, a second socket listening on INADDR_ANY is needed as you suggested; the open issue is: how to tell the agent task to open this socket and listen on it as well:

I see two ways of dealing with this:

1)  an extra flag argument to 'zbeacon_t *zbeacon_new (zctx_t *ctx, int port_nbr)', which is passed to s_agent_task()
2)  leave zbeacon_new() alone, and introduce a new API call which will eventually instruct the agent task to open/listen/poll the second socket, by passing a command via the pipe

now that I spell it out I think I'll go for 2)

---

the other new API call wont impact the existing code

//  Send a frame directed to a particular IP address once
CZMQ_EXPORT void
    zbeacon_send (zbeacon_t *self,  char *ipaddress, byte *transmit, size_t size);

- Michael


Am 30.11.2013 um 20:26 schrieb Arnaud Loonstra <arnaud at sphaero.org>:

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