anchor.diff:  
   So the source side of the connection sends a ServiceSinkReplicationHandler ( be be run on the remote machine )
   
  +
  +```
  +--- !!meta-data #binary
   csp: /replication/out-1/2
   cid: 292323922173575
  +--- !!data #binary
   handler: !ServiceSinkReplicationHandler {
     queueName: out-1,
     wireType: BINARY_LIGHT,
  
positive.code:   sourceId: !short 1002,
    sourceBuilderClass: !type ServiceSourceReplicationHandlerBuilder
  }
  
  
  
  As mentioned above the SubHandler that will be run for all messages that contain the following meta data
  
  --- !!meta-data #binary
  csp: /replication/out-1/2
  
  or
  
  --- !!meta-data #binary
  cid: 292323922173575
  
  
  and the Sink side of the connection, respond and setup a ServiceSourceReplicationHandler to be run on the other host.
  
  DocumentContext:
  --- !!meta-data #binary
  csp: /replication/out-1/2
  cid: 292323922173575
  
negative.code: 
  == Audience
  
  Anyone who wants to get a bit more inside into the data transefer between the remotes host of queue replication. This document is not a user functionally guide.
  
  Chronicle Queue Enterprise replication uses an UberHandler. UberHandlers act as message routers, They are  serialised locally then sent to the remote host via tcp/ip, The serialised form of UberHandler looks as follows ( see below )
  
  ```
  --- !!data #binary
  handler: !net.openhft.chronicle.network.cluster.handlers.UberHandler {
    remoteIdentifier: 1,
    localIdentifier: 2,
    wireType: !WireType BINARY_LIGHT,
    clusterName: global
  }
  ```
  
  Chronicle Queue Enterprise typically sends its messages in binary wire format see net.openhft.chronicle.wire.BinaryWire. This is a  binary form of YAML, however to make the messages human readable in this document, we will show the message in text wire  see net.openhft.chronicle.wire.TextWire.
  
  