I'd vote for new State. Alternatively the wsConnecting could be used but
there could be more unexpected cases when state is "connecting" but
socket is still invalid.
I found another issue. If we call Close on a socket, DNS lookup isn't
cancelled. I experienced this problem when lookups were delayed due to
network being down. Then timeout triggered, socket was closed and
connected again which resulted in "Connect: Socket already in use"
exception. The fix is to add "InternalCancelDnsLookup(True);" as the
first line to TCustomWSocket.InternalClose. To test this case, I used
|blackhole.webpagetest.org| (|184.108.40.206|) as DNS server in network
adapter settings (found this solution here
BTW, DnsLookup contains almost the same code to clean up a previous
lookup as InternalCancelDnsLookup. Seems to me the code is safe to be
replaced by method call.
Just tried using wsoAsyncDnsLookup in a new component, and discovered a
flaw in the implementation.
Currently wsocket State is not changed when the DNS lookup starts, so
it remains wsClosed, and applications are not aware it's happening, and
it may take several seconds, or longer. So there is a risk of a second
There is FInternalDnsActive flag which could be published and checked,
or we could add a new State wsDnsLookup which would be easier to use
since mostly we check for not wsClosed.
But I'm always reluctant to change long defined stuff in case someone
is checking for State >= wsClosed for instance, not a good design
generally since it assumes the type has an order.
So which change is safer?
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be