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();
if (rv != APR_FROM_OS_ERROR(WSAEWOULDBLOCK)) {
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.
