The returned data is
Per-message arrays.
Index 0 is total number of $ThisType messages received since program start (or uint64 counter wrap).
Index 1 is total byte count since program start (or uint64 counter wrap).
They are returned as strings due to unfortunate JSON implementations in the field that do not handle unquoted uint64 numbers correctly.
Peer information. Returns number of inbound, outbound and total peers. Total peer count is equivalent to RPC 'getconnectioncount'.
The returned data is
1. Per-message arrays.
Index 0 is total number of $ThisType messages
received since program start (or uint64 counter wrap).
Index 1 is total byte count since program start (or uint64
counter wrap).
They are returned as strings due to unfortunate JSON implementations
in the field that do not handle unquoted uint64 numbers correctly.
2. Peer information. Returns number of inbound, outbound and total peers.
Total peer count is equivalent to RPC 'getconnectioncount'.
Sample output here: https://gist.github.com/2980975
Design doesn't feel quite right to me.
How about something like:
getpeerinfo : returns list of peers (ip address, inbound/outbound, etc)
getstat "which_stat_to_get" : generic RPC call for getting internal state of bitcoin...
getstat "which_stat_to_get" would make it easier to wrap up in a snmp style poller, e.g. for graphing with an rrd tool frontend.
@gmaxwell all the kernel interfaces that SNMP uses tend to return groups of statistics that the kernel finds easy to generate together (tx pkts, rx pkts, rx bytes, tx bytes, collisions, ...) I see the same pattern elsewhere. So perhaps 'getstat $STAT' can return complex objects, if it is natural to do so internally.
Regardless... closing. will work on 'getpeerinfo' and then see what's left.