anchor.diff:  
   Because Cluster's Consensus Module requires that we write a log file to support the Raft protocol, we need a client for
   the constructed Archive for it to use. As the Consensus Module should always be deployed on the same node as its
  -archive, we're going to use the local (IPC) configuration.  It is also worth noting that we haven't changed the
  -controlRequestStreamId in our setup.  The defaults in this situation are the most appropriate (from Aeron version 1.33.0
  -onwards).
  +Archive, we're going to use the local (IPC) configuration. It is also worth noting that we haven't changed the
  +`controlRequestStreamId` in our setup. The defaults in this situation are the most appropriate (from Aeron version
  +1.33.0 onwards).
   
   ==== Consensus Module
   
  
positive.code: 
  Next we are going to push messages into the cluster itself. So that the client is able to fail over to different nodes,
  as nodes come and go, in the cluster the Aeron publications are contained in a class called `AeronCluster`. This is the
  second of the two items that are connected at start up. This class provides an API very similar to the Publication API.
  
  [source, Java, indent=0, options="nowrap"]
  ----
  include::{sampleSourceDir}/io/aeron/samples/cluster/tutorial/BasicAuctionClusterClient.java[tag=publish]
  ----
  
  <1> In much the same way that we would send messages to a publication we put the data that we want to send into an
  Agrona `DirectBuffer`. The `AeronCluster` contains offer methods that behave in the same way as the `Publication` offer
  methods.
  
  <2> Publish the data in the same way we would with a `Publication`. We must check the return value to ensure that the
  message has been sent because back pressure could happen at any time.
  
  <3> If we fail to send, and need to run an idle loop, we should utilise an `IdleStrategy` to ensure that we don't
  inappropriately overuse the CPU. With cluster clients we should also be continually polling the egress stream to pick
  up any messages that have been sent back from the cluster, including errors or session status messages.
  
  === Receiving Responses
  
  As was mentioned previously, our client must have a class which implements the `EgressListener` interface to receive
  messages that come back from the cluster. The responses can be application messages, session events (e.g. error
  messages), or notifications of a new leader. In this tutorial there is not a lot to do, therefore we simply print out
  the responses that received.
  
  [source, Java, indent=0, options="nowrap"]
  ----
  
negative.code: === Handling Messages
  
  The `onSessionMessage` callback is the main entry point for requests coming into the cluster. Messages reach here by
  being published to the Cluster's ingress channel. This method will also be passed messages during log replay. It is from
  within this method we will interact with our application logic. Cluster also provides a reliable timestamp as a
  parameter to this method. As mentioned earlier this is one of the challenges of building deterministic systems. Use
  this value as the timestamp within your application state, so it will be consistent under replay.
  