CBLListener is not publishing bonjour service

[Victor Fernandez]

Hi, I'm using native CouchbaseLite for Objective-c for starting a CBLListener with a specific type and name. This is the code:

NSString *url=[NSString stringWithFormat:@"http://%@:59840/%@",ip,bucketNameConfigStr];
CBLManager* manager = [CBLManager sharedInstance];
self.listener = [[CBLListener alloc] initWithManager: manager port: 59840];
self.listener.requiresAuth=NO;
[self.listener setBonjourName:url type:serviceType];
NSError *error;
BOOL ok = [self.listener start:&error];
if(ok){
      NSLog(@"Listener Url: %@", self.listener.URL);
}

The listener always initialized correctly but not always published the bonjour service. Does anyone have an idea of why this could be happen?

Regards

[Jens Alfke]

On Jun 29, 2015, at 10:30 AM, Victor Fernandez <vfern...@txmglobal.com> wrote:

NSString *url=[NSString stringWithFormat:@"http://%@:59840/%@",ip,bucketNameConfigStr];

...

[self.listener setBonjourName:url type:serviceType];

That’s a weird use of the service name: it’s supposed to be human-readable since it tends to show up in browseable lists. If you’re trying to communicate the listener’s URL to clients that are browsing, that’s not the right way to do it — instead the client should resolve the service and use the resolved hostname. (My P2P sample app shows how to do this.)

I think that “:” and “/“ are valid characters in the service name, but maybe not; that could explain why your service doesn’t get published.

Also, have you used an app like Bonjour Browser to verify that the service isn’t published?

—Jens

[Victor Fernandez]

Yeah, I'm using Bonjour Browser for testing. I already change the name of the service (I use the advertisement identifier cause UUID is deprecated).

The service still not being published. The funny thing is that with the simulator everything works fine but with a physical device the listener does not publish the service. 

Any other ideas?

[Jens Alfke]

Check your WiFi network. Some base stations are configured to prevent clients from being able to send packets to each other; it's for security apparently, but it breaks Bonjour completely, of course.

—Jens 

--
You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/79b87b20-4a12-40bf-bedf-01b3161517df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Victor Fernandez]

I already did a test with a MCNearbyServiceAdvertiser and the service is been published correctly so I don't think this is the problem. 

[Jens Alfke]

On Jul 1, 2015, at 7:43 AM, Victor Fernandez <vfern...@txmglobal.com> wrote:

I already did a test with a MCNearbyServiceAdvertiser

On the same device?

and the service is been published correctly so I don't think this is the problem. 

If the base station is blocking p2p traffic, the device publishing the service won’t be able to tell. It just sends DNS packets over multicast; it doesn’t know whether any other device receives them.

—Jens

[Victor Fernandez]

Actually it was a network configuration problem, thanks for the advice. I'm starting the listener in the delegate method didBecomeActive and also I'm stoping him in the delegate method willResignActive but I'm notice that after a while even the listener is stopped the service still being published. This only happens after do several times the exercise of active/inactive app.
Is there a way to do a force quit of the service?
The code that I'm using for stop the listener is:

if (self.listener) {
        [self.listener stop];
        self.listener = nil;
}