I'm trying to figure out what should happen in
dnssd_clientstub.c:deliver_request when socket creation fails on the
server.
I have an embedded platform using the Posix daemon. Every so often, we
run out of TCP sockets. If we run out of TCP sockets in deliver_request
we are fine and the error is sensibly processed. If we run out of TCP
sockets in uds_daemon.c:request_callback (about line 765) the responder
daemon keeps running but DNSServiceUpdateRecord (which calls deliver
request) in the client never returns. Somehow, whatever that call is
waiting for never happens and my client locks up.
I've traced the code, but it's hard to see by inspection what is
supposed to happen.
I think I've figured it out. For some reason, some commands set up a
second socket for error notification (reuse_sd is 0 - *why* does it do
this?). This routine calls 'listen (listenfd, 1)'. If the matching socket
on the other end fails to initialise then that 'listen' will never return.
Sure, there's a backlog of '1', but we're the only client and we're hung
then there's nothing to add to the backlog.
Sound plausible? What's the fix?
--
Andrew White
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bonjour-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/bonjour-dev/email@hidden
