CBLReplication with only Peer-Peer WiFi and no Bluetooth

[Phaniteja N]

We are working on peer to peer replication in the latest CouchbaseLite using CouchbaseListener. We have identified that replication takes too much of time whenever there are three devices connected to each other. In the Logs, we get frequent Bluetooth disconnection messages  -  BTM: disconnection to service 0x00000800 on device "Device A" 60:FE:C5:99:79:54 succeeded

Whenever this message is received the netServiceDidStop and the netServiceBrowser:didRemoveService:moreComing delegate methods gets called. Apple has acknowledged that this is a problem with Bluetooth.

To solve this problem can we use CBLReplication without Bluetooth i.e only with Peer-Peer WiFi?

[Jens Alfke]

> On Sep 18, 2014, at 12:46 AM, Phaniteja N <phanitej...@gmail.com> wrote:
>
> To solve this problem can we use CBLReplication without Bluetooth i.e only with Peer-Peer WiFi?

(I've actually never heard of anyone doing replication over Bluetooth before!)

This sounds like a Bonjour question, not a Couchbase Lite question — CBL's replicator will connect to whatever hostname or IP address you provide in the URL. It's just using NSURLConnection, and it doesn't know what the underlying network is.

It sounds like when you resolve the NSNetService it's giving you an IP address that's bridged through Bluetooth, when what you want is a real IP address from the WiFi LAN. The question is how to resolve the other address. From what I remember, NSNetService will give you an array of all the addresses it resolved; you'll need to pick out the one you want somehow.

—Jens

[Phaniteja N]

Hello Jens,

"When we use Peer-Peer WIFI alone for data transfer between two devices, the following happens in both the devices

• Peer publication is ok. (netServiceDidPublish triggered)
• Devices are able to identify each other(netServiceBrowser:didFindService:moreComing:(BOOL)moreServicesComing triggered and peers identified)
• IP Address of the peers is resolved successfully(netServiceDidResolveAddress triggered and the correct sync URL http://deviceA:5601/ReplDB is also formed)
• But the kCBLReplicationChangeNotification is posted. Notification observer is available in the code. This does not work for Push/Pull Replication.
  

The same code works if Bluetooth is turned ON. Could you please help.

Thanks

[Phaniteja N]

Hello Jens,
Made a minor change in the text.

• But the kCBLReplicationChangeNotification is not posted. Notification observer is available in the code. This does not work for Push/Pull Replication.
  

Thanks.

On Tuesday, September 30, 2014 3:38:33 PM UTC+8, Phaniteja N wrote:

Hello Jens,

"When we use Peer-Peer WIFI alone for data transfer between two devices, the following happens in both the devices

• Peer publication is ok. (netServiceDidPublish triggered)
• Devices are able to identify each other(netServiceBrowser:didFindService:moreComing:(BOOL)moreServicesComing triggered and peers identified)
• IP Address of the peers is resolved successfully(netServiceDidResolveAddress triggered and the correct sync URL http://deviceA:5601/ReplDB is also formed)

• But the kCBLReplicationChangeNotification is not posted. Notification observer is available in the code. This does not work for Push/Pull Replication.
  

[Jens Alfke]

On Sep 30, 2014, at 12:38 AM, Phaniteja N <phanitej...@gmail.com> wrote:

• IP Address of the peers is resolved successfully(netServiceDidResolveAddress triggered and the correct sync URL http://deviceA:5601/ReplDB is also formed)

• But the kCBLReplicationChangeNotification is not posted. 

There's a huge distance between those two bullet points. To find out what happened in between, turn on logging (see the wiki for details.) I'd try the Sync log keyword first; add SyncVerbose if you're not seeing any interesting logs.

(What does the replication's status end up as?)

Also, "http://deviceA:5601/ReplDB" isn't a URL I'd expect; did you simplify the host portion in your post? You should end up with a URL like "http://10.0.1.19/ReplDB", or whatever actual numeric IP address the host resolved to.

—Jens

[Phaniteja N]

Hi,
Thanks a lot for your support.

Please find below the observations with Sync logs enabled:

1) When we get a IPV6 address while resolving ,replication is not successful ,We get Sync Logs as below
 <Warning>: Sync: CBL_Puller[http://fe80::68c8:cfff:fef9:3856:54571/cabincrew]: Reachability state = <fe80>:unreachable (00), suspended=0

2) When we get a IPV4 address While resolving,replication is successful.We get Sync Logs as below
<Warning>: Sync: CBL_Puller[http://169.254.44.229:54557/cabincrew]: Reachability state = <169.254.44.229>:reachable (20002), suspended=0
Oct  9 10:37:30 GREEN CabinCrew.0.0.27jun[1193] <Warning>: Sync: CBL_Puller[http://169.254.44.229:54557/cabincrew]: Going online
Oct  9 10:37:30 GREEN CabinCrew.0.0.27jun[1193] <Warning>: Sync: CBL_Puller[http://169.254.44.229:54557/cabincrew] Progress: set active = 1

We get the IPV4 address only when bluetooth is switched on randomly i.e 1 out of 5 times. In addition, [NSNetService addresses] returns only one address from the array. Is it possible in some way to convert IPV6 address to IPV4 address or else retrieve the IPV4 address always?

-Phani

[ajres]

When passing an ipv6 based URL to create a replicator, try enclosing the ipv6 address with [] e.g.:

http://[fe80::68c8:cfff:fef9:3856]:54571/cabincrew

Andy

[Phaniteja N]

Hi,
The issue still exists even though the ipv6 address is enclosed with [].  Please find the logs below

<Warning>: Sync: CBL_Puller[http://[fe80::14ed:73ff:fe79:4416]:57912/cabincrew]: Reachability state = <fe80::14ed:73ff:fe79:4416>:unreachable (00), suspended=0

We were asked to resolve and use IPV4 from array of addresses (Ref: https://github.com/couchbase/couchbase-lite-ios/issues/236). But the issue is the [NSNetservice addresses] returns only one address which is IPV6 and not IPV4.

- Phani

[Jens Alfke]

On Oct 10, 2014, at 1:56 AM, Phaniteja N <phanitej...@gmail.com> wrote:

1) When we get a IPV6 address while resolving ,replication is not successful ,We get Sync Logs as below
 <Warning>: Sync: CBL_Puller[http://fe80::68c8:cfff:fef9:3856:54571/cabincrew]: Reachability state = <fe80>:unreachable (00), suspended=0

That's not a warning, just a regular log. But if you're not seeing subsequent logs showing that the host is reachable (as below), that means the SystemConfiguration reachability API isn't working.

My guess is that your URLs aren't valid. The regular ASCII representation of an IPv6 address has colons in it, but I don't think those are legal in the hostname portion of a URL, since the colon is already the delimiter between the hostname and the port.

I have no idea how to encode an IPv6 address into the hostname of a URL, but you can probably find the answer with a bit of web searching, or maybe by asking on StackOverflow.

Is it possible in some way to convert IPV6 address to IPV4 address or else retrieve the IPV4 address always?

I don't know. This has something to do with the way Apple's network stack is tunneling IP through Bluetooth. I suggest you ask on Apple's developer forums or their macnetworkprog mailing list.

—Jens

[Jens Alfke]

For future reference: Quinn from Apple developer support recommends using the NSNetSevice's hostName property to construct the URL, instead of resolving the raw IP (v4 or v6) addresses. This pushes the actual job of address resolution down to the system frameworks, which know how to pick the best address.

The hostName will end with ".local.", e.g. "jens.local."

Note that you still need to resolve the service before getting the hostName property.

—Jens

[Lakshminarayana Achar]

We have been using NSNetSevice's hostName property to construct the URL,but  in order to investigate the issue we started using the raw IP addresses.

Please find the logs  below

With Bluetooth

Oct 20 13:52:23 BLUE P2PApp.0.0.27jun[143] <Warning>: SyncURL=http://GREEN.local.:49680/Appdb

Oct 20 13:52:23 BLUE P2PApp.0.0.27jun[143] <Warning>: Sync: CBLReplication[from http://GREEN.local.:49680/Appdb]: offline, progress = 0 / 0, err: (null)

Oct 20 13:52:23 BLUE P2PApp.0.0.27jun[143] <Warning>: Replication is created with URL: http://GREEN.local.:49680/Appdb

Oct 20 13:52:23 BLUE P2PApp.0.0.27jun[143] <Warning>: Sync: CBL_Puller[http://GREEN.local.:49680/Appdb] STARTING ...

Oct 20 13:52:23 BLUE P2PApp.0.0.27jun[143] <Warning>: Sync: CBL_Puller[http://GREEN.local.:49680/Appdb]: Reachability state = <GREEN.local.>:reachable (20002), suspended=0

Oct 20 13:52:23 BLUE P2PApp.0.0.27jun[143] <Warning>: Sync: CBL_Puller[http://GREEN.local.:49680/Appdb]: Going online

Oct 20 13:52:23 BLUE P2PApp.0.0.27jun[143] <Warning>: Sync: CBL_Puller[http://GREEN.local.:49680/Appdb] Progress: set active = 1

Oct 20 13:52:23 BLUE P2PApp.0.0.27jun[143] <Warning>: SyncVerbose: CBL_Puller[http://GREEN.local.:49680/Appdb]: postProgressChanged (0/0, active=1 (batch=0, net=1), online=1)

Oct 20 13:52:23 BLUE P2PApp.0.0.27jun[143] <Warning>: SyncVerbose: CBL_Puller[http://GREEN.local.:49680/Appdb]: GET _local/f51417be40be320c42ec828d9467c3ac249b593e

Oct 20 13:52:23 BLUE P2PApp.0.0.27jun[143] <Warning>: SyncVerbose: CBL_Puller[http://GREEN.local.:49680/Appdb]: postProgressChanged (0/0, active=1 (batch=0, net=1), online=1)

Oct 20 13:52:23 BLUE P2PApp.0.0.27jun[143] <Warning>: Sync: CBLReplication[from http://GREEN.local.:49680/Appdb]: active, progress = 0 / 0, err: (null)

Oct 20 13:52:23 BLUE P2PApp.0.0.27jun[143] <Warning>: completedChangesCount: 0   changesCount: 0

Without Bluetooth(Peer-Peer Wifi)

Oct 20 12:44:13 GREEN P2PApp.0.0.27jun[157] <Warning>: SyncURL=http://BLUE.local.:49375/Appdb

Oct 20 12:44:13 GREEN P2PApp.0.0.27jun[157] <Warning>: Sync: CBLReplication[from http://BLUE.local.:49375/Appdb]: offline, progress = 0 / 0, err: (null)

Oct 20 12:44:13 GREEN P2PApp.0.0.27jun[157] <Warning>: Replication is created with URL: http://BLUE.local.:49375/Appdb

Oct 20 12:44:13 GREEN P2PApp.0.0.27jun[157] <Warning>: Sync: CBL_Puller[http://BLUE.local.:49375/Appdb] STARTING ...

Oct 20 12:44:13 GREEN wifid[40] <Notice>: WiFi:[435482053.228573]: WiFiVirtualInterfaceStartResolvingService: called key = <data> 0x055f73713233c00c000c01, value = <data> 0x04424c5545c027

Oct 20 12:44:13 GREEN P2PApp.0.0.27jun[157] <Warning>: Sync: CBL_Puller[http://BLUE.local.:49375/Appdb]: Reachability state = <BLUE.local.>:unreachable (00), suspended=0

Looks like a reachability issue.

Is there something that can be done from our end or your end to fix the issue ?

[Jens Alfke]

On Oct 20, 2014, at 2:47 AM, Lakshminarayana Achar <brl...@gmail.com> wrote:

Looks like a reachability issue.

Is there something that can be done from our end or your end to fix the issue ?

Weird. Yes, from the logs it looks like the SCNetworkReachability API isn't behaving correctly with WiFi. Which is the opposite of what I'd expect; since IP-over-Bluetooth is unusual, I'd expect that to be the configuration with problems.

I'm assuming that to do the WiFi-only test you simply turned off Bluetooth on the device?

I don't think I'm doing anything wrong with the (fairly simple) reachability API. If you want to dig further, you can add breakpoints or logging in CBLReachability.m, to see if you can get any more idea of what's going on.

—Jens

[Jens Alfke]

On Monday, October 20, 2014 11:11:50 AM UTC-7, Jens Alfke wrote:

On Oct 20, 2014, at 2:47 AM, Lakshminarayana Achar <brl...@gmail.com> wrote:

Looks like a reachability issue.

Is there something that can be done from our end or your end to fix the issue ?

Weird. Yes, from the logs it looks like the SCNetworkReachability API isn't behaving correctly with WiFi. Which is the opposite of what I'd expect; since IP-over-Bluetooth is unusual, I'd expect that to be the configuration with problems.

After some discussion with Quinn of Apple's developer tech support, it sounds like (a) SCNetworkReachability isn't returning the correct results in the case of an ad-hoc (no base station) WiFi network, and (b) one shouldn't rely on reachability to preflight making a connection — instead we should try to connect regardless.

It looks like despite all this discussion no bug report has been filed, so I'll create one now.

—Jens

[Jens Alfke]

I don't know; you're the first to try this. You'll need to experiment to figure out what's going on. Something seems to be wrong at the NSURLConnection level; it's not able to connect. 

—Jens 

On Nov 12, 2014, at 9:43 PM, Br Achar <br.a...@tcs.com> wrote:

Jens,

We have tried syncing by removing the preflight connection check.We get a request timeout error as in the logs as below.

2014-11-12 17:43:46.909 SampleApp.0.0.27jun[877:139523] Sync: CBLReplication[from http://DeviceA.local.:58640/sampledb]: offline, progress = 0 / 0, err: (null)

2014-11-12 17:43:46.910 SampleApp.0.0.27jun[877:139523] Replication is created with URL: http://DeviceA.local.:58640/sampledb

2014-11-12 17:43:46.921 SampleApp.0.0.27jun[877:140111] Sync: CBL_Puller[http://DeviceA.local.:58640/sampledb] STARTING ...

2014-11-12 17:43:46.950 SampleApp.0.0.27jun[877:140111] Sync: CBL_Puller[http://DeviceA.local.:58640/sampledb]: Going online

2014-11-12 17:43:46.957 SampleApp.0.0.27jun[877:140111] Sync: CBL_Puller[http://DeviceA.local.:58640/sampledb] Progress: set active = 1

2014-11-12 17:43:46.963 SampleApp.0.0.27jun[877:140111] SyncVerbose: CBL_Puller[http://DeviceA.local.:58640/sampledb]: postProgressChanged (0/0, active=1 (batch=0, net=1), online=1)

2014-11-12 17:43:46.966 SampleApp.0.0.27jun[877:140111] SyncVerbose: CBL_Puller[http://DeviceA.local.:58640/sampledb]: GET _local/528a42c96259b10800762a87d9090da7cc844253

2014-11-12 17:43:46.999 SampleApp.0.0.27jun[877:140111] SyncVerbose: CBL_Puller[http://DeviceA.local.:58640/sampledb]: postProgressChanged (0/0, active=1 (batch=0, net=1), online=1)

2014-11-12 17:43:47.006 SampleApp.0.0.27jun[877:139523] Sync: CBLReplication[from http://DeviceA.local.:58640/sampledb]: active, progress = 0 / 0, err: (null)

2014-11-12 17:44:00.018 SampleApp.0.0.27jun[877:139523] completedChangesCount: 0   changesCount: 0

2014-11-12 17:44:16.496 SampleApp.0.0.27jun[877:139523] DeviceA is stop service

2014-11-12 17:45:00.224 SampleApp.0.0.27jun[877:140111] CBLRemoteJSONRequest[GET http://DeviceA.local.:58640/sampledb/_local/528a42c96259b10800762a87d9090da7cc844253]: Got error Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo=0x18263b90 {NSErrorFailingURLStringKey=http://devicea.local.:58640/sampledb/_local/528a42c96259b10800762a87d9090da7cc844253, NSErrorFailingURLKey=http://devicea.local.:58640/sampledb/_local/528a42c96259b10800762a87d9090da7cc844253, NSLocalizedDescription=The request timed out., NSUnderlyingError=0x181c2390 "The request timed out."}

Please advise us on what can be done since P2P bluetooth is unreliable one.

Thanks & Regards
Lakshminarayana Achar B R
Tata Consultancy Services
Cell:- 9940021554
Mailto: br.a...@tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________

-----Jens Alfke <jens....@gmail.com> wrote: -----

To: mobile-c...@googlegroups.com
From: Jens Alfke <jens....@gmail.com>
Date: 11/12/2014 11:07PM
Cc: phani...@tcs.com, rubha.s...@tcs.com, br.a...@tcs.com, kanya...@tcs.com
Subject: Re: CBLReplication with only Peer-Peer WiFi and no Bluetooth

On Monday, October 20, 2014 11:11:50 AM UTC-7, Jens Alfke wrote:

On Oct 20, 2014, at 2:47 AM, Lakshminarayana Achar <brl...@gmail.com> wrote:

Looks like a reachability issue.

Is there something that can be done from our end or your end to fix the issue ?

Weird. Yes, from the logs it looks like the SCNetworkReachability API isn't behaving correctly with WiFi. Which is the opposite of what I'd expect; since IP-over-Bluetooth is unusual, I'd expect that to be the configuration with problems.

After some discussion with Quinn of Apple's developer tech support, it sounds like (a) SCNetworkReachability isn't returning the correct results in the case of an ad-hoc (no base station) WiFi network, and (b) one shouldn't rely on reachability to preflight making a connection — instead we should try to connect regardless.

It looks like despite all this discussion no bug report has been filed, so I'll create one now.

—Jens

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you