That's a good idea but I have a couple concerns that maybe you can address.

I'm thinking that allocating a random TCP port might lead to random failures
of future programs as they are unable to allocate the port they need to
listen on. Especially because Windows uses ports 1025-5000 as its default
ports.

Also, would any aggressive firewalls block or pop up messages to users if a
TCP were used?

-Costa

On Sat, Aug 8, 2009 at 5:13 PM, Jamie Lokier <jamie_at_shareable.org> wrote:

> Constantine Sapuntzakis wrote:
> > P.S. I considered an approach of using WSAWaitForMultipleEvents
> > instead off select and having the async name resolver call a
> > user-defined callback that woul do a QueueUserApc on the waiting
> > thread to wake up the WSAWaitForMultipleEvents when the name
> > resolution was done. This has the advantage of not polling but the
> > disadvantage of requiring W2K or above and rewriting my select-based
> > to code to use WSACreateEvent/WSAEventSelect/WSAWaitForMultipleEvents.
> > I also considered using ARES but my app requires religiously following
> > the Windows DNS suffix rules for non-FQDN names.
>
> You can create a self-connected socket on Windows (and on unix).
> Create a TCP socket bound to AF_INET 127.0.0.1, port zero.
> getsockname() to get which port it was really bound to, and listen().
> Then create another TCP socket and connect it to the address returned
> from getsockname().
>
> Then you can write to the socket from your resolver thread when it's
> done, and monitor the socket from your select() loop.
>
> -- Jamie
>
Received on 2009-08-09