anchor.diff:  each service. Each endpoint will be an offset from the first port in a node's range. E.g. the archive control request
   port has an offset of 1, so for Node 2 it will have port 9201.
   
  -To start the cluster node we are going define our own class with a main method.  It will construct and start all of the
  +To start the cluster node we are going define our own class with a main method. It will construct and start all of the
   necessary components. As indicated above we are going to give each node of the cluster a unique id (0, 1, and 2). We are
   also going to use this value as the cluster member id.
   
  
positive.code: 
  === Other events
  
  There a number other events received by the `ClusteredService` interface, such as timer events, clients connecting and
  disconnecting from the cluster, and leadership and role changes. We won't look at these in this tutorial.
  
  == Configuring a Cluster
  
  Now we have our application implemented we can move onto running it in a cluster. There are a number of moving parts to
  setting up a cluster node, one of the trickiest parts of using Aeron Cluster is getting the configuration correct. We
  are going to start with a static three-node cluster with a simplified configuration where all the components
  (MediaDriver, Archive, ConsensusModule and ClusteredServiceContainer) for a single node withing a single process. Later
  we will then start the cluster as three separate processes.
  
  === Running Multiple Nodes on the Same Host
  
negative.code: 
  Within Aeron Cluster, replication (ensuring that a follower node has the same state as the leader) and recovery
  (restoring a stopped node to its previous state)footnote:[Where stopping could include crashing or manually shutting
  down] are the same problem, or at least at similar enough, to use the same mechanism. They rely on three functions.
  Firstly, some known initial state, this could either be the state when first provisioned (a 'null' or empty state), or
  some snapshot of state at a point in time. Secondly, an ordered log of all input messages, this is handled by Cluster's
  Raft implementation. Thirdly, the application logic needs to be deterministic, i.e. it must derive all of its resulting
  