httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Speeding up mod_proxy_balancer on Windows
Date Mon, 13 Oct 2008 16:51:17 GMT
Ruediger Pluem wrote:
> Not exactly. I would prefer to fix the basic issue with Windows. If we need to
> support milliseconds for connection timeouts seems to be another story for me.
> Can some of the Windows gurus come to the rescue to either confirm and explain
> why it takes that long for connect to return after trying to connect to a closed
> port (on the same machine !!!) or if this must be a local issue on a specific machine.

Apparently, nobody is using apr_socket_connect() much on win32 to have noticed this
before, but the implementation;

    if (connect(sock->socketdes, (const struct sockaddr *)&sa->sa.sin,
                sa->salen) == SOCKET_ERROR) {
        int rc;
        struct timeval tv, *tvptr;
        fd_set wfdset, efdset;

        rv = apr_get_netos_error();
            return rv;
        if (sock->timeout < 0) {
            tvptr = NULL;
        else {
            /* casts for winsock/timeval definition */
            tv.tv_sec =  (long)apr_time_sec(sock->timeout);
            tv.tv_usec = (int)apr_time_usec(sock->timeout);
            tvptr = &tv;
        rc = select(FD_SETSIZE+1, NULL, &wfdset, &efdset, tvptr);

is so suboptimal, it might as well be pure posix.  It's obviously
msvcrt select() implementation which ignores tv_usec based on the
reporters comments.

So where does this leave us?  Just set a damned event for the completion
context of connect (or WSAConnect) and block on the event with exactly
the timeout you want (using [WSA]WaitForSingleObject).  That should provide
near-instant acknowledgment of success or failure.

Because mod_ftp PORT needs the behavior, I can play with this pretty
readily late in the week or at the con.

View raw message