Ahh, now that you mention this, I recall another thread on this forum where that idea came up!
You mentioned that sn_authd does something like this already, so I took a look at that as well. The library qjsonrpc currently sits in the sn_api crate, but are there any plans to spin it off into its own crate? It seems that, if one were to remove the specific references to sn_authd, it could semi-readily be re-used in sn_node or elsewhere we wanted.
Just thinking out loud now, but some of the json-rpc types are also agnostic of quic (e.g. JsonRpcRequest and friends ), so it may be possible to bring those in as a dependency eventually and cut down on code. Admittedly, I, personally, don’t know of any crates that offer just the json-rpc data types as of right now.
As far as cleaning up node resources on exit goes, the reason I ask is because I was thinking it might make some of the error handling simpler and result in a bit faster node operation. Certain operations could definitely benefit from not having to anticipate a sudden termination at any moment.
Here’s one example that comes to mind. If we had a clear exit path we wouldn’t need to sync_all() so much when storing chunks. The process of storing the used storage value, syncing to disk, storing the chunk, and syncing again could be simplified (and sped up) to storing the used value and the chunk without any flush to disc, trusting the node will sync the OS buffer to disk when the program exits properly (given that a SIGKILL termination would not ensure any of the data makes it disk). Then the node isn’t obligated to ensure a graceful exit on sudden termination, which seems more in line with the purpose of killing a process aggressively (like when using SIGKKILL).
