mirror of https://github.com/status-im/op-geth.git
p2p/simulations: improve README language (#24051)
This commit is contained in:
parent
a25906e4c0
commit
acb0f7a67b
|
@ -1,7 +1,7 @@
|
|||
# devp2p Simulations
|
||||
|
||||
The `p2p/simulations` package implements a simulation framework which supports
|
||||
creating a collection of devp2p nodes, connecting them together to form a
|
||||
The `p2p/simulations` package implements a simulation framework that supports
|
||||
creating a collection of devp2p nodes, connecting them to form a
|
||||
simulation network, performing simulation actions in that network and then
|
||||
extracting useful information.
|
||||
|
||||
|
@ -65,10 +65,10 @@ localhost ports.
|
|||
|
||||
## Network
|
||||
|
||||
A simulation network is created with an ID and default service (which is used
|
||||
if a node is created without an explicit service), exposes methods for
|
||||
creating, starting, stopping, connecting and disconnecting nodes, and emits
|
||||
events when certain actions occur.
|
||||
A simulation network is created with an ID and default service. The default
|
||||
service is used if a node is created without an explicit service. The
|
||||
network has exposed methods for creating, starting, stopping, connecting
|
||||
and disconnecting nodes. It also emits events when certain actions occur.
|
||||
|
||||
### Events
|
||||
|
||||
|
@ -80,7 +80,7 @@ A simulation network emits the following events:
|
|||
|
||||
The events have a "control" flag which when set indicates that the event is the
|
||||
outcome of a controlled simulation action (e.g. creating a node or explicitly
|
||||
connecting two nodes together).
|
||||
connecting two nodes).
|
||||
|
||||
This is in contrast to a non-control event, otherwise called a "live" event,
|
||||
which is the outcome of something happening in the network as a result of a
|
||||
|
@ -98,12 +98,12 @@ network and then wait for expectations to be met.
|
|||
With a running simulation network, the `Simulation.Run` method can be called
|
||||
with a `Step` which has the following fields:
|
||||
|
||||
* `Action` - a function which performs some action in the network
|
||||
* `Action` - a function that performs some action in the network
|
||||
|
||||
* `Expect` - an expectation function which returns whether or not a
|
||||
given node meets the expectation
|
||||
|
||||
* `Trigger` - a channel which receives node IDs which then trigger a check
|
||||
* `Trigger` - a channel that receives node IDs which then trigger a check
|
||||
of the expectation function to be performed against that node
|
||||
|
||||
As a concrete example, consider a simulated network of Ethereum nodes. An
|
||||
|
@ -116,7 +116,7 @@ the expectation and what network events were emitted during the step run.
|
|||
|
||||
## HTTP API
|
||||
|
||||
The simulation framework includes a HTTP API which can be used to control the
|
||||
The simulation framework includes a HTTP API that can be used to control the
|
||||
simulation.
|
||||
|
||||
The API is initialised with a particular node adapter and has the following
|
||||
|
|
Loading…
Reference in New Issue