anchor.diff:  eos: !!null "" #  END_OF_STREAM
   ```
   
  -The sink replication handler then receives new messages from the SourceReplicationHandler. When it receives these new messages it uses a chronicle queue appender to write them to a chronicle queue. 
  +The sink replication handler then receives new messages from the SourceReplicationHandler. When it receives these new messages it uses a chronicle queue appender to write them to a chronicle queue.
   
   NOTE: When the messages are written to the chronicle queue by the `SinkReplicationHandler`, we write the message and take account of the source index, to guarantee that the order of messages from the source exactly matches the order of messages on the sink. In addition, using the index also ensures that the message has always been written to the correct queue file. This is even if events such has roll-over have occurred. This would typically cause a normal appender to write the message to the next queue file. This is not what we want, because we create an exact copy of messages, from the source to the sink.
   
  
positive.code: 
  Heartbeat handlers are set up on both the source, and the sink machines. Periodically (set using the `heartbeatIntervalMs` field) they send a heartbeat message to their corresponding remote host. If the `heartbeatTimeoutMs` has passed and no heartbeat message has been received, then the heartbeat handler will close the socket connection and attempt to reconnect.
  
  === Exchanging data between Source and Sink 
  
  Chronicle queues are replicated using the `SourceReplicationHandler`, which sends its messages to the `SinkReplicationHandler`. Both the `SourceReplicationHandler` and `SinkReplicationHandler` are SubHandlers.
  
  
negative.code: 
  When the Uberhandler is loaded by the remote machine, its `onInitialize()` method is automatically called (`see
   net.openhft.chronicle.network.cluster.handlers.UberHandler#onInitialize`).
  
  NOTE: When sending the Uberhandler, only its data is serialised. The Java byte code of the Uberhandler must already
   exist on the remote machine. Only the data of the Uberhandler instance is sent, not the byte code for the Uberhandler
  