anchor.diff:  
   === Sending data with the SourceReplicationHandler
   
  -The SourceReplicationHandler sends messages to the SinkReplicationHandler. The SourceReplicationHandler uses a chronicle tailer to read new messages from your chronicle queue, the messages will be written to the queue by your application logic. When the SourceReplicationHandler comes to read the contents of this chronicle queue, it does not deserialize the message in any way, it  just treats the message as a blob of bytes and writes the bytes to the replication event, also known as the `re` in the message below: 
  +The `SourceReplicationHandler` sends messages to the `SinkReplicationHandler`. The `SourceReplicationHandler` uses a Chronicle tailer to read new messages from your Chronicle queue. The messages will be written to the queue by your application logic. When the `SourceReplicationHandler` comes to read the contents of this Chronicle queue, it does not de-serialize the message in any way, it treats the message as a blob of bytes, and writes the bytes to the replication event. This is also known as the `re` in the message below:
   
   ```
   --- !!meta-data #binary
  
positive.code: }
  ```
  
  HeartbeatHandlers are set up on both the source and sink machines. Periodically ( set via 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), the HeartbeatHandler will close the socket connection and attempt to reconnect.
  
  == Source Replication Handler
  
  Chronicle Queues are repliated using the SourceReplicationHandler, which sends its messages to the SinkReplicationHandler. Both the SourceReplicationHandler and SinkReplicationHandler are SubHandlers
  
  However handshaking messages are send back from the SinkReplicationHandler to the SourceReplicationHandler, one such message is the acknowledgement message which the sinks sends the source. By inspecting the `idx: 0x451600000000` ( see message below ) this alows you to added code on your source machine to ensure that message was received by the remote machine and therefore replicated.
  
  ```
  --- !!meta-data #binary
  
negative.code: 
  = Chonicle Queue Enterpise - TCP/IP Repliction Protocol
  :toc:
  :toc-title: Contents
  :toclevels: 1
  
  == Overview
  This document describes the high-level protocol and handshaking that is used by Chronicle Queue Enterprise to replicate data using TCP/IP to queues that are running on different machines.
  
  === Message format in this document
  
  Chronicle Queue Enterprise sends its messages in binary wire format (see `net.openhft.chronicle.wire.BinaryWire`); this is a  binary form of `YAML`.
  
  In order to make the messages human-readable in this document, the messages are shown in text wire format (see `net.openhft.chronicle.wire.TextWire`).
  
  === Who should read this
  
  Anyone who wants to get more information into the data that is transfered between the remote hosts used by Chronicle Queue Enterprise to do TCP/IP replication. This document is not a queue functionality overview document.
  
  == Uberhandler
  
  Chronicle Queue Enterprise replication uses an UberHandler. UberHandlers act as message routers, They are serialised locally, and then sent to the remote host using TCP/IP. The serialised form of UberHandler is shown below:
  
  ```
  --- !!data #binary
  