On Feb 17, 2004, at 12:07 AM, Marc Krochmal wrote:
Scott,
On Feb 15, 2004, at 9:38 AM, Scott Atchley wrote:
I was thinking that we would need to build the mDNSResponder into our
server, but it seems that we should simply provide a link in our
documentation to where our users can get it at Apple if they want to
run this on *nix or Windows. We would then make using
Rendezvous/ZeroConf an optional part of our server configuration
(--with-mdns=<path>). If configured to use Rendezvous/ZeroConf, then
it would start up, announce itself and then listen for requests.
I'm not sure what your target audience is. If your user's don't mind
agreeing to the APSL by registering in order to get a user name and
password, and if they don't mind learning how to use cvs to get the
latest mDNSResponder that includes the daemon for *nix, then yes this
is one solution. However, I wouldn't recommend this. Is there a
problem with bundling the daemon with your server?
Can more than one mDNSResponder exist on a host? If not, then I don't
want to assume that our server will be able to run one. If so, how do
they both listen on the same multicast port?
Correct me if I am wrong, but it seems to me that the mDNSResponder
daemon simply caches previous service advertisements so that clients on
the same machine can query it and keep overall network traffic down.
Does it do anything else? If there is not a client on the same host,
what purpose does it serve? Does it reply to service requests over the
network instead of the actual service provider (our server in this
case)?
Our server users are Unix/Linux sysadmins. They are used to using
./configure and prefer that dependancies be handled with the
--with-<library>=/path/to/libary construct. As far as bundling goes, I
am willing to provide the mDNSResponder code with our server as a
separate tarball. This allows us to drop in updated mDNSResponder as it
comes out. If the user so opts, then ./configure will include the
#ifdef'd code that handles Rendezvous and our server will link against
the mdns library. In the mDNSResponder code that I downloaded and
built, I don't see any .a or .dyld libraries, so we may have to create
one for us to link against.
As for the client browsing without touching the network, the client
must be running a mDNSResponder for this to work? In our case, the
server and client are never on the same machine (except for testing).
I'm not sure that the machine running our server even needs
mDNSResponder at all as long as our app is listening for requests.
Most of the time the client will send packets on the network when
browsing. You can either compile the mDNSResponder code directly into
your client and server, or you can run the daemon. Either way, you'll
need the mDNSCore code from the mDNSResponder project.
Best Regards,
-Marc
Thanks for your help,
Scott
_______________________________________________
rendezvous mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/rendezvous
Do not post admin requests to the list. They will be ignored.
