...
Abstract
Clients needs information about Iroha entities outside `WorldStateView`:
Peer's Health Check
Peer's Management - start, stop
Resources Monitoring - CPU, Memory and Disk consumption
Business Measurements of Iroha
Transactions per second amount
Blocks Storage size
- Submitted transactions statuses changes
- Blocks statuses changes
...
Introduction
For some clients and for Iroha administrators it is important to have more information than provided by the Data Model.
One of such a cases were described by the following requirements:
- Client should receive status changes of all
...
- transactions submitted by this client.
...
- Iroha Peer should guarantee that changes submitted to the client goes over synchronous protocol and messages received by client if peer and client are connected.
- If peer, client or network goes down - Client should use another API to check current status of entities needed.
- Iroha Peer will not store information about status changes and they may be lost.
- iroha Peer will provide information available for this peer only.
- The same functionality should be provided to monitor blocks statuses.
Because transactions states changes are not stored on the Blockchain and can't be presented in World State View `Maintenance Endpoint` is a good place to add this functionality to.
Results
As a result Iroha provides an additional endpoint for maintenance purposes, described in Abstract.
Some of requests answered with "current state" responses information like CPU and Memory consumption.
For "subscribe" functionality connection should be permanent and still - network problems, peers or clients disconnections and other troubles will lead to automatic end of "subscription".
Security aspect
To prevent secured information losses `subscribers` should receive only information they had permissions to have.
The "CanAnything" permission will provide information about the entire system and most of maintenance endpoints will require accounts with it.
If account has no "CanAnything" permission, it's signature should be presented in transactions to receive information about their states changes. client receives such statuses after 'submission'
- If subscription was initiated after transaction was committed to the block client will not receive this transaction statuses and should query missed block or be subscribed on committed blocks stream.* Client should be aware of "its" transactions statuses (list of statuses)
* Guarantees of that statuses receiving by clients
** If client missed something it will query information
* What to do on_subscribe? (Batch of pendings?)