The most robust implementations I've seen use the API provided by this
The API which Avahi project (for linux) says is not recommended
because it does not support avahi's extra features. However I would
ignore that since "dns_sh.h" is not only feature-complete, but also
much more cross-platform compatible than Avahi's native API which
can't ever be compatible to run on mac os x. All macs have
mdnsresponder which conflicts with the Avahi daemon.
The "dns_sd.h" API is pretty straightforward and gets the job done.
I would recommend to use it above all the others mDNS APIs. On windows
you must link to the lib which is installed when Bonjour is installed.
On Linux, install Avahi service which comes with avahi's compatibility
version of "dns_sd.h".
There is also a ruby gem named "dnssd" which compiles its C extension
against "dns_sd.h". You can browse the source code for that on github.
On Wed, Aug 31, 2011 at 8:18 AM, Jens Alfke <email@hidden> wrote:
> On Aug 31, 2011, at 12:05 AM, email@hidden wrote:
> The source port of my outgoing UDP replys seem to change on each
> broadcast message.
> I don’t have an answer to your exact question (been too long since I used
> UDP), but I can tell you that it’s a bad idea to use broadcast. It will
> create work for the network interface and IP stack of every single device on
> the LAN, because every device has to listen to all broadcast packets. This
> is a bad idea on busy networks.
> What you should be using instead is link-local multicast. It has the same
> basic behavior, except that only network interfaces that are explicitly
> listening on your multicast address will handle the packet; others can just
> ignore it. This is how Bonjour works, for example. (And it was Stuart
> “Bonjour” Cheshire who first explained to me the difference, ten years ago.)
> My guess about your port issue is that your code is specifying what port it
> wants to send *to* on the destination, but it hasn’t specified which port
> it’s sending *from*.
> PS: Please don’t BCC the mailing list in your posts. It breaks people’s
> auto-filtering mail rules, and makes it awkward to reply back to the list.
> Do not post admin requests to the list. They will be ignored.
> Macnetworkprog mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> This email sent to email@hidden
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden