Related to #37, we should persist some kind of ZUnique_id_t buffer across restarts so we don't get ourselves caught between a retransmit silly across restarts. Or just stuff it in the database... it doesn't have to mean a new database query per message because we can suck up the last however many on startup and rely on libzephyr's internal one from there.
It's not super-likely, except in the face of broken cross-realm zephyrds. Can work around it by just dropping garbage packets, but this would be prudent nonetheless.
Also the ZUnique_id_t's are probably handy anyway for correlating outgoing and incoming messages.
Related to #37, we should persist some kind of ZUnique_id_t buffer across restarts so we don't get ourselves caught between a retransmit silly across restarts. Or just stuff it in the database... it doesn't have to mean a new database query per message because we can suck up the last however many on startup and rely on libzephyr's internal one from there.
It's not super-likely, except in the face of broken cross-realm zephyrds. Can work around it by just dropping garbage packets, but this would be prudent nonetheless.
Also the ZUnique_id_t's are probably handy anyway for correlating outgoing and incoming messages.