anchor.diff:  }
   ```
   
  -When ever your application appends data to the source queue, The SourceReplicationHandler will read this queue  ( by using a queue tailer ) and then stream any new data to the remote host imediatly. As such Chronicle Queue Enterprise establishes a stream rather than a polling protocol. If the network buffers are full then data won’t be sent by the SourceReplicationHandler. So its not strictly `reactive` but rather sensitive to push back, and given that chronicle queue enterprise is back by chronicle queues which pages its data to disk rather than holding it all in memory, chronicle queue won’t get saturated by a slow consumer, as the data is not paged into memory from the queue until the tcp/ip buffers have sufficient free space.
  +Whenever your application appends data to the source queue, the `SourceReplicationHandler` will read this queue using a queue tailer, and then immediately stream any new data to the remote host.
  +
  +Chronicle Queue Enterprise establishes a stream rather than a polling protocol. If the network buffers are full, then data will not be sent by the `SourceReplicationHandler`. Therefore, it is not strictly reactive, but rather, it is sensitive to push back.
  +
  +Chronicle Queue Enterprise uses queues which page data to disk, rather than holding it all in memory. Therefor Chronicle Queue will not get saturated by a slow consumer, because the data is not paged into memory from the queue until the TCP/IP buffers have sufficient free space.
   
   == ServiceSinkReplicationHandler
   
  -Before the sink replication handler starts to read messages from the source machine, it first copies back  messages from the sink machine to the source machine. ( we call this the back copy ). This  often never happens but in the rare event, that the source machine was replicating to two ( or more sinks ) if the source had an outage, and we failed over to one of the remaining sinks, we want to ensure which ever sink we choose, it has the latest messages, and hence in the event that one of the sinks has more messages than the other we will first copy any messages from the other sink before we establish this sink as our new source.
  -
  -When the ServiceSinkReplicationHandler starts it calls software.chronicle.enterprise.queue.replication.SinkReplicationHandler#onInitialize
  -
  -Once all the data has been replicated, to notify the SourceReplicationHandler that the back copy is now complete a END_OF_STREAM message is sent
  +Before the sink replication handler starts to read messages from the source machine, it first copies back  messages from the sink machine, to the source machine; this is called the back copy.
  +
  +Although rare, it is useful for example, if the source machine was replicating to two (or more) sinks, and the source suffered a power outage. +
  +Chronicle will fail-over to one of the remaining sinks, and therefore we need to ensure that, whichever sink is chosen, it has the latest messages. +
  +Therefore, in the event that one of the sinks has more messages than the other, we will first copy any messages from the other sink before we establish this sink as our new source.
  +
  +When the `ServiceSinkReplicationHandler` starts, it calls `software.chronicle.enterprise.queue.replication.SinkReplicationHandler#onInitialize`.
  +
  +When all the data has been replicated, an `END_OF_STREAM` message is sent to notify the `SourceReplicationHandler` that the back copy is complete.
   
   ```
   --- !!meta-data #binary
  
positive.code: }
  ```
  
  Once the message is received by the sink it send an acknologment to the source
  
  ```
  --- !!meta-data #binary
  
negative.code: }
  ```
  
  The sink-side of the connection will respond by setting up a `SourceReplicationHandler` to be run on the other host.
  
  ```
  --- !!meta-data #binary
  