[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