Skip to content

GitLab

Add getmempoolinfo RPC wrapper to API

Merged Justin Holmes requested to merge Justaphf/thehub:feature/getMempoolInfo_RPCwrapper into master

This is just adding a RPC wrapper for getmempoolinfo to the hub API. I marked this as WIP due to having some outstanding questions about the proper setup, which I am documenting as comments in the review as well as a list below. If you feel this is sufficient as-is feel free to take out of WIP and merge.

Background is that I've updated txVulcano to be able to target a mempool size rather than a block size when used on scalenet. This is to deal with the fact that external entities could be adding transactions so we shouldn't rely on just the transactions we are adding and that we rely on external miners to produce blocks, which have no guarantee of being any particular size. During early testing someone must have come over from testnet v4 because they were only mining 2 MB blocks. By checking what the hub's current mempool size is we can direct txVulcano to add transactions with the goal of keeping the mempool full enough such that it is always possible to produce full blocks, even if we have no guarantee that a miner actually mines a full block.

Notes and questions:

  1. Initially I'm just wrapping the RPC call. It would probably be more performant to re-implement as a direct parser instead, wrapping the RPC was just quicker to implement.
  2. Based on comments and placement in APIProtocol.h, it seems this RCP call was intended to be under a new HubControlService. I wasn't sure how to properly set up a new service not directly known/owned by the APIServer, as noted by the comment in ServiceIds enum, so I just stuck it in the existing LiveTransactionService as that seemed the closest category match to what is actually reported by getmempoolinfo.
  3. I wasn't sure how to properly compute the message size for the reply so I just set it to something well above what is needed (500). I'm not sure if a hard-coded default that's above what it needs to be has any detrimental side-effects. I suspect it just affects the size of a buffer, but the message size should be fixed since it's just 5 8-byte fields. I could probably just let the default calculateMessageSize execute, but this seems like a low-effort/low-risk micro-optimization, so why not just do it.
Edited by Justin Holmes