4

I have two iOS devices finding each other successfully using the Bonjour API, but since they are both simultaneously publishing and browsing, they also see themselves appearing in the list of available services. There must be some bit of information each endpoint can use to determine that a service is their own and exclude it from their list... I'm sure I just missed it somewhere - any ideas?

I have used the examples from the docs with a few small changes.

Kara
  • 6,115
  • 16
  • 50
  • 57
iforce2d
  • 8,194
  • 3
  • 29
  • 40

3 Answers3

4

mDNS doesn't make any distinction between device boundaries- every mDNS resolver on the link-local network listens for all multicast packets sent to 224.0.0.251 by default regardless of origin. Think of it as a glorified short-wave radio. Well, kind of.

That means when you browse for services, NSNetServiceBrowser doesn't discriminate between hosts (and there are times when I've found that to be a useful feature in server-side applications).

I'd suggest the easiest way to ignore your own services is to check that the hostname of the NSNetService object returned in the netServiceBrowser:didFindService:moreComing: callback isn't yours before doing whatever you need to do with it.

Chris Mowforth
  • 6,689
  • 2
  • 26
  • 36
  • Thanks Chris. I'll give this the green tick because it seems like it's the best that can be done. I did think of this earlier but was hoping there was a more definitive way than checking textual names, which could be the same on different devices. – iforce2d Nov 10 '11 at 16:14
  • 2
    You could instead set a unique ID in the TXT of the service so that you can recognize yourself. See http://stackoverflow.com/a/15835190/161972 for UUID. – huyz Jul 10 '14 at 01:02
  • @huyz yep, that'd do it – Chris Mowforth Jun 19 '17 at 00:48
0

I am using IOS 8.1 and I had the same question. I ended up comparing the name of each service returned by didFindService against the name of the local NSNetService representing my bonjour server.

Based on what I see debugging my app, the hostname of each NSNetService is nil until the service is resolved. In my case I did not call resolveWithTimeout inside didFindService because I guess it would take too long to display the data.

boggy
  • 3,674
  • 3
  • 33
  • 56
0

As hinted by the accepted answer, compare the NSNetService name to the device name:

- (void)netServiceBrowser:(NSNetServiceBrowser *)aNetServiceBrowser didFindService:(NSNetService *)aNetService moreComing:(BOOL)moreComing
{
    // Ignore the local device if specified
    if ([aNetService.name isEqualToString:UIDevice.currentDevice.name])
    {
        NSLog(@"NETSERVICE: Ignoring NetService for self: '%@'", aNetService.name); 
    }
    else
    {
        ...
    }

    // If that's it then stop the browser (it's manually controlled)
    if (!moreComing) {
        [_netBrowser stop];
    }
}
Hari Honor
  • 8,677
  • 8
  • 51
  • 54
  • As mentioned in my comment on the accepted answer, this does not work if two devices have the same name. – iforce2d Jul 21 '15 at 03:34
  • 1
    Also, I've found that UIDevice.currentDevice.name is not always the same as the device's bonjour network name! I'm not sure how to directly get a device's bonjour network name, but in my case I'm using network MIDI, so instead of the above check, I compare [aNetService.name isEqualToString:[MIDINetworkSession defaultSession].networkName] – Chadwick Wood Aug 06 '15 at 23:35
  • I've been using this technique exactly like this for years. But since we know you're doing this for MIDI, note that the `MIDINetworkSession` has a `networkName` which is what you're supposed to use, maybe? I'll try that now – Dan Rosenstark Oct 28 '16 at 23:36
  • Sorry: I already do that **and** I also check against the currentDevice.name. That works pretty well... if either of those are true, it's ourselves. Now... if I could actually control what name is actually used by the `MIDINetworkSession.defaultSession` I'd be happy. Oh, Chadwick already said all this. Anyway, moving right along... – Dan Rosenstark Oct 28 '16 at 23:38