I just tried to connect two android devices with replication. Both are in a local LAN.
At startup I start a pull-replication (not continuous) for initial syncing and a continuous push-replication.
The data is replicated as it should, but the database change events all have the ‘external’ flag set to false.
When both devices only run a continuous pull-replication and no push, the external flag is correct.
Is this by design or is it a bug?
Push replication probably requires less network resources than pull, so it would be preferable.
With the sync gateway I usually use push and pull.
But I tried to use push only with the sync gateway: the push from one client is not forwarded through the gateway and thus the second client never gets any update (I guess this is the normal behavior with the sync gateway without pull).
I think there is a bit of misunderstanding here about what is really going on. When you do a push replication, it means that you are asking to copy a document, which exists in the local dataset, into a remote database. In P2P specifically, this is just a REST endpoint which triggers a document to be added locally using the library and so is not considered “external.” Pushing a document to Sync Gateway will create the document on Sync Gateway but you are responsible for pulling it from Sync Gateway on other clients.
Pull replications, on the other hand, have a defined remote source, since they are designed to take data from remote and save it locally.
Push replication probably requires less network resources than pull, so it would be preferable.
Not sure what you mean by this. They both require a similar amount of network interaction.
That’s kind of how I pictured it. Except for the bold part. I still think it would be good to have the real source (the pushing DB) and the external flag set true for these changes on the receiving end.
My guess was that pull has to constantly poll the other DB for changes. The application will be in a very low bandwidth scenario, with mobile devices connected over UHF radio. I probably have to create my own exchange system for this.
The pushing database would not be available at that point. The best we’d be able to do is get the IP address that the request came from since the REST request simply contains a document to add and no other information other than standard HTTP (or web socket) headers and information. Changing this would require changes all around the board on all platforms to maintain interoperability and backwards compatibility and so is not likely to happen.
Pulling and Pushing are meant to indicate direction, and not the actions that people have come to associate with them. Pulling will only poll if it is set to continuous, and even then it keeps existing connections open until it receives information so it’s not consistently asking.
As far as bandwidth goes, the biggest source of bandwidth usage is document attachments. Everything else is pretty tight, with the overhead coming mostly from stuff from the HTTP protocol. In fact we are currently in the process of evaluating a replacement for HTTP that requires fewer connections and less bandwidth so keep checking around in the coming weeks / months if you are interested.