[nas] sleep(1)s in ConnSvr.c
Jon Trulson
jon at radscan.com
Sun Aug 3 22:25:48 MDT 2008
On Sun, 3 Aug 2008, Kris Marsh wrote:
> Hi guys,
>
> I'm just wondering about the rationale for the sleep(1) at
> ConnSvr.c:895 ConnSvr.c:1060 and ConnSvr.c:1104.
>
> It seems to me that they're all basically pausing after a failed
> {UNIX,tcp} socket connection. What I'm wondering is why this is
> happening, and also the reasoning behind the retries. Is it expected
> that re-trying a failed connection after a second would ever succeed?
>
Apparently (according to the comments) it wasn't possible to
distinguish between the case where a server was not even listening
on the port, and the case where a server was present, but it's
listen() backlog was exceeded. In that case, it is probable that
the client could succeed in a future attempt.
That said, I am not sure how valid that is anymore - specifically,
is there now a way to properly distinguish between the two events?
If so then the sleep/retry would be correct for the backlog case,
and a waste of time for the no-server case :)
> Ultimately, I would love to see these sleeps removed (attached patch),
> and also the #define AU_CONNECTION_RETRIES 5 at ConnSvr.c:84 set to 0
> - is there any likelihood of this happening? My application is pausing
> for 5 secs before it can continue if a NAS server is unable to be
> contacted.
>
To be honest, I am not sure how often a backlog-exceeded condition
appears these days.
It looks like the code would work as you prefer if you simply
re-defined AU_CONNECTION_RETRIES to 0. Have you tried this?
Maybe that should be the default (or configurable)?
--
Happy cheese in fear | Jon Trulson
against oppressor, rebel! | mailto:jon at radscan.com
Brocolli, hostage. -Unknown | #include <std/disclaimer.h>
More information about the Nas
mailing list