The built-in mDNS implementation is adjusted in such a way, that it can share and re-use the RX/TX pair of buffers which are also used by the exchange/Matter transport layer. While not an enormous memory saving (~ 3K), it paves the way for the upcoming changes to the Exchange layer itself, where the existing PacketBuffers structure (~ 25K) is gone and everything works with this single RX/TX pair - at least with regards to the exchange layer (Secure Channel won't need extra RX/TX either, the IM layer is another story but still overall a big win).
Additional gains:
I was finally able to const-ify the Matter::new / Matter::new_default constructors (thanks to const-ifying the mDNS construction itself which required changing a few HashMaps to BTreeMaps)
This is also a win for memory, as now the compiler can generate the layout of the Matter object and everything in it at compile time, put the result in the rodata section (= flash), and for creation of a "real" Matter object, just take the raw memory, memcpy into it the Matter object initial state from rodata and be done with it - no extra temporary memory necessary.
In future, the const constructors would allow us to offer users to allocate the Matter object statically and not put it on stack or in a Box. As in static MATTER: Matter<'static> = Matter::new(...). Still some work here, but we are approaching this status quo.
UdpSend and UdpReceive traits are renamed to NetworkSend and NetworkReceive. They also now take/return our own Address enum rather than a SocketAddr. Reason: I'm relatively certain we'll be able to re-use them with minor to no changes for modeling the BLE transport and TCP, as from the POV of Matter, these protocols still operate in a packetized manner (i.e. with a 2-bytes len prefix in front of each packet for TCP)
NetworkReceive has an additional method now - wait_available which is the key for sharing the RX/TX buffers from above. Basically, I'm only async-locking the RX buffer and giving it to either mDNS or Matter transport when the socket below tells us that there is a packet waiting for us in the OS network stack queue - via wait_available. This method is already implemented for STD/async-io, can be implemented for baremetal embassy-net/smoltcp with a small PR I'll contribute to them, and finally, at the price of... an additional RX buffer can be implemented for exotic OSes, though I doubt there would be any that won't natively support it. :)
Finally, the changes from above no longer force the user to create the mDNS service separately - as long as the user is not providing their own one to the Matter object (MdnsService::Provided(_)), the Matter constructor will just construct our pure-Rust one, or the Bonjour one or the Avahi one, depending on the OS.
The built-in mDNS implementation is adjusted in such a way, that it can share and re-use the RX/TX pair of buffers which are also used by the exchange/Matter transport layer. While not an enormous memory saving (~ 3K), it paves the way for the upcoming changes to the Exchange layer itself, where the existing
PacketBuffersstructure (~ 25K) is gone and everything works with this single RX/TX pair - at least with regards to the exchange layer (Secure Channel won't need extra RX/TX either, the IM layer is another story but still overall a big win).Additional gains:
const-ify theMatter::new/Matter::new_defaultconstructors (thanks toconst-ifying the mDNS construction itself which required changing a fewHashMaps toBTreeMaps)Matterobject and everything in it at compile time, put the result in therodatasection (= flash), and for creation of a "real"Matterobject, just take the raw memory,memcpyinto it theMatterobject initial state fromrodataand be done with it - no extra temporary memory necessary.constconstructors would allow us to offer users to allocate theMatterobject statically and not put it on stack or in a Box. As instatic MATTER: Matter<'static> = Matter::new(...). Still some work here, but we are approaching this status quo.UdpSendandUdpReceivetraits are renamed toNetworkSendandNetworkReceive. They also now take/return our ownAddressenum rather than aSocketAddr. Reason: I'm relatively certain we'll be able to re-use them with minor to no changes for modeling the BLE transport and TCP, as from the POV of Matter, these protocols still operate in a packetized manner (i.e. with a 2-bytes len prefix in front of each packet for TCP)NetworkReceivehas an additional method now -wait_availablewhich is the key for sharing the RX/TX buffers from above. Basically, I'm only async-locking the RX buffer and giving it to either mDNS or Matter transport when the socket below tells us that there is a packet waiting for us in the OS network stack queue - viawait_available. This method is already implemented for STD/async-io, can be implemented for baremetalembassy-net/smoltcpwith a small PR I'll contribute to them, and finally, at the price of... an additional RX buffer can be implemented for exotic OSes, though I doubt there would be any that won't natively support it. :)Finally, the changes from above no longer force the user to create the mDNS service separately - as long as the user is not providing their own one to the
Matterobject (MdnsService::Provided(_)), theMatterconstructor will just construct our pure-Rust one, or the Bonjour one or the Avahi one, depending on the OS.