chrysn
chrysn
* HAS_RECVERR sits in socknumbers * has_reuse_port sits in defaults Both should be in defaults. Granted, for has_reuse_port there may be a case for overriding it while there is none...
While doing research for multicast I stumbled upon [MSG_CONFIRM](https://manpages.debian.org/buster/manpages-dev/send.2.en.html), which reads like it'd help reduce traffic. It's not fully clear how this would work, but given that we do have...
With the `setup.py` tests breaking down and the migration to tox, not all scenarios can be easily tested any more. Possibly due to https://bugs.debian.org/962654 (where the workaround is some help...
Currently, aiocoap answers to way too many requests sent over multicast (even pings, which is not addressed separately as a `GET /` has the same effect). The default options for...
When iterating asynchronously over observation results, it appears (from code review due to #186, not direct testing) that cancelling the request/observation will keep the `async for` loop stuck indefinitely. It...
The current strategy of aiocoap to deduplicate everything can lead to memory requirements of around bandwidth times EXCHANGE_LIFETIME; even a 10MBit Ethernet link makes that peak at 300MB plus overheads....
This causes tests failures when running OSCORE plugtests 5 and 6 against a server that is just recovering its replay window. This is rather tricky to debug as the backtrace...
The WIP implementation of OSCORE B.1.1 (incrementing persisted sequence numbers in jumps of `k`) currently blocks while persisting sequence numbers. This only happens every `k` received packages, but should still...
At least when no block size is negotiated, notifications produce updates exceeding the default datagram size, possibly getting lost in transmission. Steps to reproduce: * Sniff on loopback interface *...