...
Sequence diagram (click to enlarge/download):
Points of interests/issues
Processing of round configurations
- The round entries in the benchmark configuration file are processed both by caliper-flow and default-test. This is partly because of the convenience array notation in the round configs, but with that, the processing should be performed entirely by default-test, which should be renamed to TestOrchestrator.
- The mentioned array notation is rarely used, plus its intended functionality is easy to replicate with YAML anchors. To this end, it should be removed, and one round entry should have exactly one associated rate controller, tx number/duration, etc. This would make the processing easier.
Separation of concerns
- The package should be restructured based on what modules are used in the master process and client processes. A lib/master and /lib/worker directory structure would help (lib/common for the reusable modules).
- Processing of TX result collections is also scattered among multiple modules (like the *TxStats functions on the Blockchain base class). Maybe this will be easier to resolve once the observer/monitor/reporter concerns are a bit formalized.
Inter-process communication
The IPC is all around the ClientOrchestrator module. We must hide the actual communication technology from the module. It should only interact with "client handle objects" that map high-level calls (like init, or test) to IPC and wrap the replies with easy-to-manage Promises. Each worker should have a corresponding "handle object" in the master process, that hides the entire IPC. This will make it easy to switch to other messaging libs.
Observers, monitors, reporters
The above concepts are kind of fuzzy right now, meaning they don't have a well-defined purpose. What kind of data do they need? When do they need it? What do they do with it? Are they present in the master process or in the workers?
TBD.