Couchbase lite 2.5 peer to peer replication

I’m trying to setup peer to peer connection between active peer device and a passive peer device, and trying to start the replication once both the devices are connected. I’m using the following MessageEndpointTarget object and starting the replication.

val messageEndpointTarget = MessageEndpoint(
                UUID.randomUUID().toString(), // Randomly generated ID got Active device.
                undueId, // Unique ID of the passive device.
                this // Callbacks.
        val config = ReplicatorConfiguration(cbHelper?.db!!, messageEndpointTarget)
        replicator = Replicator(config)

However, I get the following error message Got LiteCore error: LiteCore error 10 “BLIP protocol error: Bad incoming RES #123 (too high)” once the replication starts.

Here is the log related to the error:

2019-11-08 12:08:45.443 15924-16133/com.<package>.dev E/CouchbaseLite/REPLICATOR: {Repl#3}==> N8litecore4repl10ReplicatorE /data/user/0/com.<package>.dev/files/gh-dev.cblite2/ ->x-msg-endpt:////_blipsync @0x7cca5ed8c8
2019-11-08 12:08:45.444 15924-16133/com.<package>.dev E/CouchbaseLite/REPLICATOR: {Repl#3} Got LiteCore error: LiteCore error 10 "BLIP protocol error: Bad incoming RES #123 (too high)"
2019-11-08 12:08:45.447 15924-16133/com.<package>.dev E/CouchbaseLite/REPLICATOR: {Repl#3} Stopping due to fatal error: LiteCore error 10 "BLIP protocol error: Bad incoming RES #123 (too high)"

Please can you let me know why this error is occurring, and if there is a sample project I can refer to?

Thank you.

You can get a sample implementation from the person managing your Couchbase Support, assuming you have an enterprise subscription. This is an enterprise feature so there is not an open source sample project. As far as why the error is occurring, the message means that an invalid response was received from the other side of the replication process. There is no request 123 to go along with the response 123 for some reason and so the response came for a non-existent request. The likelihood of the library causing this is low, but not zero. It’s more likely some mistake in the connection transport code.

Your transport has probably accidentally dropped a message, or delivered messages in the wrong order.

I’d say that the problem here is that your messages come in the incorrect order. At least it looks that way