5

I'm using NSNetService and NSNetServiceBrowser to publish and scan for Bonjour services on the network. The implementation is working fine, the services are found on the network and they are capable of communicating. I'm currently trying to understand the framework's lifecycle and this what I've got so far:

// Scanning
netServiceBrowserWillSearch:
netServiceBrowser:didFindService:moreComing: // The device finds itself

// Advertising
netServiceWillPublish:
netServiceDidPublish:

This happens if I start the services with the adapter on. Now I need to know, at all times, whether the service is being actively advertised on the network; that is, if other devices are capable of finding it. So I test it with turning the Wi-Fi adapter off:

netServiceBrowser:didRemoveService:moreComing:
netServiceBrowser:didFindService:moreComing: // The device finds itself again, even after the adapter is turned off

Then I turn the adapter back on:

netServiceBrowser:didRemoveService:moreComing:
netServiceBrowser:didFindService:moreComing: // Yet again

The problem is that there is absolutely no difference in turning the adapter on or off, so I can't look for a pattern. Is there any other way that I can catch these events?

Edit: It gets worst. Even if I start the services with both adapters off (airplane mode) netServiceDidPublish: still gets called. So far it seems that netServiceDidNotPublish: is called only when I try to register the same service twice. This is very counter intuitive to me; maybe the service got published to the adapter, but not the network, and as such these callbacks are very misleading. At this point there is no way I can know whether the service is visible on the network.

André Fratelli
  • 5,920
  • 7
  • 46
  • 87

1 Answers1

0

For future reference, I needed to use workarounds to solve this. The problem is that Bonjour publishes its services to the protocol stack, so the adapter never gets queried for state. This makes sense, as Bonjour is a multi-transport protocol. In order to solve this I used an adaptation of Apple's reachability framework to listen to adapter state changes for Infrastructural Wi-Fi, at which point I query the adapter for the presence of the adwl0 interface for Wi-Fi direct support. Important note: that article claims to find support for general Wi-Fi connectivity which is not true; the awdl0 interface is the Wi-Fi Direct interface, which is why this will fail in devices such as the iPhone 4/4S. This is OK, because those devices do not support Wi-Fi Direct. As Bonjour also works with Bluetooth, I use CoreBluetooth to listen to Bluetooth adapter state changes. Although this framework is meant for Bluetooth Low Energy, I believe the Bluetooth adapter being on is a strong assurance that the Bonjour services are visible on the network. It's a bit unfortunate that Apple doesn't allow doing this without workarounds, but that's what we get, I guess.

André Fratelli
  • 5,920
  • 7
  • 46
  • 87