Need to Bonjour twice?

I launch a TCP listening server on port 66661. I create a Bonjour notification about this. No problems.

Before anyone connects at 66661 the app creates another unrelated network service (another TCP listening server) on another port, and in an identical fashion creates a Bonjour advertisement, this time on 66662.

That also works perfectly, and devices can see the Bonjour ad and thence connect at 66662.

Note that 66661 should, and does, still work allowing that other type of player to connect there...no problem.

HOWEVER ... I have found that -- after 66662 -- the bonjour advertisement for 66661 is flakey.

Sometimes it is there / sometimes it disappears. (We've not been able to find an exact pattern.)

Has anyone seen this sort of flakeyness in Bonjour, after starting a second Bonjour ad?

A workaround solution .. After 66662 is happy, I just create another identical Bonjour ad for 66661. An exact repeat of the earlier Bonjour code advertising 66661.

This appears to cause no problem, and indeed, does appear to work perfectly on volume iOS apps with no complaints, crashes etc. But it is weird.

Question 1, I BELIEVE that technical note QA1333 suggests it is perfectly OK to make two or more such Bonjour incidents. Anyone know about this, is that correct, ever DTSed the issue?

Question 2, why would the first Bonjour advertisement stop working -- sometimes yes, sometimes no -- in the situation where you have created another one?

Has anyone seen this? Any ideas? Cheers.

From Kevin's suggestion: yes, we t开发者_StackOverflow中文版est this thoroughly with tools like Bonjour Browser and numerous devices/Macs.

From Jarrod's suggestion: yes, when it does stop/disappear, it stops "for all clients". I think I actually do not know how to tell programmatically (on the server) if it is "unregistered".

Try running dns-sd -B _blah._tcp. . in the terminal from any Mac on your LAN. This will open up a query on that service and you can watch the Add and Remove events come by. This is a good way to verify that your service is being explicitly deregistered, rather than (just as an example) not broadcasting properly once new clients start listening after the fact.

Bonjour is multicast UDP, UDP by definition is un-reliable. Messages can and do get lost.

You don't make it clear whether the service becomes un-registered or it just appears to not be there. That would take some debugging and multiple clients to see if the service actually stops responding completely to all request to all clients or just some, or if something on the registering server is killing the service publish because of a wrong TTL or other configuration or logic error.