search

chrysn / aiocoap

The Python CoAP library
Other
262 stars 119 forks source link

Add rudimentary support for broadcast via aiosync-client #292

Open mzpqnxow opened 1 year ago

mzpqnxow commented 1 year ago

This is referenced in #291

I tried to keep this as light as possible, just to be enough to suit my needs (interfacing with a proprietary technology that uses COAP with UDP broadcast as the transport)

If you prefer this be done differently, please let me know. I'm happy to take your guidance. I'm very new to COAP and equally new to the aiocoap codebase

Thanks!

mzpqnxow commented 1 year ago

@chrysn appreciate the review, thank you! I agree 100% that it's clunky as a flag (I was cringing as I was propagating it through the call tree, ending up with new kwargs to functions)

All of the changes are no brainers, I just need to confirm whether the broadcast ioctl requires elevated privileges

Regardless, I can just catch the EPERM and per your preference (re: best-effort/don't raise on failure to set) log the failure and continue if the privileges aren't there

I will get back with updates once I've incorporated your feedback and fixed the merge conflicts that have popped up

Thanks again!

chrysn commented 1 year ago

best-effort/don't raise on failure

We have to pick one of these because we can't be sure whether a v4 address is broadcast or not, right? If so, best-effort setting it is probably an OK way. I'd like to redo the transport configuration at some point so that there's a configurable way to do this that doesn't need to thread flags through many layers, but I'm not fully clear there yet. (Could be a TOML-ish data structure that tells which protocols to bind to which ports, would allow binding to multiple ports, and setting things like multicast groups, and setting flags such as SO_REUSEPORT or this one).

chrysn commented 1 year ago

On Tue, May 16, 2023 at 05:32:44AM -0700, AG wrote:

You may wonder why on earth that would be necessary- the server software I was dealing with actually required the universal broadcast address 255.255.255.255 for a specific endpoint, and I'm working in a multi-homed environment with multiple interfaces having +BROADCAST

Given that we're on the udp6 transport that works in IPv6 semantics with all its benefits, do you really need to bind the interface, or can't you use the tuple ('::ffff:255.255.255.255', 5684, 0, interface_id) to send the request out on the right interface? That should even work with URI notation as coap://[::ffff:255.255.255.255%eth0].