Oct 24, 2025

Completed the json::rpc::request parser and json::rpc::response serializer, as well as a json::rpc::request serializer to facilitate test. Good test coverage, but I'll add a bunch more tomorrow. This also includes the type system and a reader/writer json::body<parser> for boost::asio::async_read and ::async_write, which utilizes the request parser and response serializer. The serializers are straightforward writes to a stream buffer. Currently this uses std::ostringstream, but the performance of this could be bumped up using system::ostream, as we do with p2p network and store. The parser is streaming, so can accommodate boost::asio piecemeal asynchronous buffer updates for a given request. Additionally the parser is non-allocating apart from the final copy/move of buffer values to the request object fields. Instead of pushing characters into a buffer, it moves views over the network buffer. I've dusted off the boost::json declarative serialize/deserialize that was formerly applied to all of the chain objects (and actually reimplemented both of the above serializers with it but decided in favor of the custom implementation). These conversions are almost entirely declarative and very performant. This will be used to convert the request.params object or array types from string blobs passed via in the json-rpc request/response DOM between the channel/proxy and the protocol implementations. As I outlined in the meeting, this deferred serialization simplifies the rpc layer, keeping native objects from being unnecessarily parsed in/out of a document object model. Just as with http::request and http::response objects, we'll pass these json::request and json::response objects via a message distributor template instance for the various json-rpc based channels. Protocols just subscribe and handle the request, sending the response - just as with the p2p protocols.