You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Or even create a separate GetStats request, answer to which could be populated with all kinds of info: like a number of p2p and RPC clients, a number of RPC requests responded total, TX requests and block template requests specifically, TXes included into submitted blocks, avg and max RPC request per second, blocks accepted via relay and via submitBlock, and whatever else could be interesting for the node runner.
The text was updated successfully, but these errors were encountered:
I will do this i actually think these would be interessting stats to have. I will do uptime specifically in GetInfo / maybe also number of rpc clients, and max clients, I think everything pertaining to the question of "do I want to connect to this node" shoould go into getInfo, but the rest in a new GetStats.
It might require the implementation of a small stat tracking package imo. I see this as useful for exmaple in future gui aplications, or kdx, that wrap the node with gui, and as a notification message for a livefeed of how the node is performing. It can also expose what addresses are mining to the node. Which currently is hidden.
Or even create a separate GetStats request, answer to which could be populated with all kinds of info: like a number of p2p and RPC clients, a number of RPC requests responded total, TX requests and block template requests specifically, TXes included into submitted blocks, avg and max RPC request per second, blocks accepted via relay and via submitBlock, and whatever else could be interesting for the node runner.
The text was updated successfully, but these errors were encountered: