How many concurrent connections can an application using Couchbase Lite iOS make to Syncgateway?

Is there any way to check the number of concurrent connections made from Couchbase Lite iOS to Syncgateway and also is there a way to limit the number of connections ?

Setting the context:

After a security assessment on the application we are developing, our IT team has raised a flag that they have noticed 1000+ concurrent active connections with sync gateway from each device. As per my understanding a device will maintain hardly 2 active connections to push & pull. If there is data connection loss, will Couchbase Lite close the connection?

If you are using 1.x, for a given replication, you will have a max of 2-4 TCP connections for push and pull. For 2.x, since it’s bi-directional, you should have just 1. 1000 open connections from a single client seems way off the mark.
Please double check your app logic to verify that it isn’t inadvertently creating a bunch of replications in continuous mode (for instance, every time a view is initialized).
You can run a packet trace tool (like wireshark) and see the number of connections that are initialized from a given client.

1 Like

Hi @priya.rajagopal,

   As per our code logic, database connection is a singleton object and in which both pull and push replication objects are private variables.

    if _pullReplication == nil {
        _pullReplication = createPullReplication(withDatabase: _database)

    if _pushReplication == nil {
        _pushReplication = createPushReplication(withDatabase: _database)

We are restarting the replication when ever there is a change in channel or change in data connection. (We are using current date as channel as per our business logic, on every login, we are calculating the channel and restarting the replication. Also when the device is offline, we are manually stopping the replication and starting it when the device is online again)

We will revalidate with packet trace tool and get back to you with details


OK. And you are stopping the replication when you log off , right?

Actually in continuous mode, the replicator should automatically take care of changes to network conditions . It will back off connection attempts to server when offline and will connect back when you get back online so you don’t have to manually do it. That’s one of the benefits of using continuous mode. Do you see issues in this ?

No, we are not. Because there are many scenarios where the device is offline. So we are trying to keep the replication continues before it goes offline to sync all the latest data till then

Earlier we tried that, but we didn’t see replication starting automatically when it comes from offline. So we are handling it manually based on data connection.

OK. Maybe I am misunderstanding what you mean by “offline”. When I mentioned “log off”, I was referring to the case when the user logs off / signs off of the app. To me, that’s different from the device going offline when the network is down for instance. I would think that if a user has signed out of the app that you don’t want to continue to do replication on behalf of the user (because presumably the replication is authenticated with the signed in user credentials).

Can you remind me again which version of CBL you are using? Seems like a bug to me if the replicator is not restarting when network is online again. You may want to look at the last section of this blog that talks about this …

The app is built for an enterprise and is used in a closed network and the users of the app don’t have the password. So, the replication is always authenticated by a common user and we have separate fields in the database to identify the user and their modifications. So as I said earlier, we are restarting the replication on every login as there would be a change in the channel that needs to pull also we are starting and stopping the replication based on the data connection to a device (offline -> online - start replication and online -> offline - stop replication). Apart from these scenarios, the replication is running continuously.

We are using CBLite iOS v1.4.0 (using carthage github “couchbase/couchbase-lite-ios” “release/1.4.0”)