Knowledge of bonus service status

Question

I use NSNetService and NSNetServiceBrowser to publish and test Bonjour services on the network. The implementation works fine, the services are online, and they are able to communicate. I am currently trying to understand the life cycle of a structure and this is what I still have:

// Scanning netServiceBrowserWillSearch: netServiceBrowser:didFindService:moreComing: // The device finds itself // Advertising netServiceWillPublish: netServiceDidPublish: 

This happens if I start the services with the adapter turned on. Now I need to know if the advertisement is constantly being actively advertised on the network; that is, if other devices are able to find it. Therefore, I am testing it by disconnecting the Wi-Fi adapter:

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

Then turn on the adapter again:

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

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

Edit: everything is getting worse. Even if I start the services with the adapters disabled (airplane mode), netServiceDidPublish: is still called. It still seems that netServiceDidNotPublish: is only called when I try to register the same service twice. This is very controversial for me; the service may have been published on the adapter, but not on the network, and therefore such callbacks are very misleading. At the moment, I can’t find out if the service is visible on the network.

Answer 1

In the future, for reference, I needed to use workarounds. The problem is that Bonjour publishes its services to the protocol stack, so the adapter is never queried for state. This makes sense since Bonjour is a multi-transport protocol. To solve this problem, I used the Apple reachability adaptation to listen for state changes of the adapter for infrastructure Wi-Fi, after which I request an adapter for the adwl0 interface for direct Wi-Fi support. Important note: this article claims to find support for a common Wi-Fi connection, which is incorrect; awdl0 is a Wi-Fi Direct interface, so it can crash on devices like the iPhone 4 / 4S. This is normal because these devices do not support Wi-Fi Direct. Since Bonjour also works with Bluetooth, I use CoreBluetooth to listen for state changes of the Bluetooth adapter. Despite the fact that this platform is designed for Bluetooth Low Energy, I believe that the Bluetooth adapter is a reliable guarantee that Bonjour services are visible on the network. It’s a little annoying that Apple does not allow doing this without workarounds, but this is what we get, I think.