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| (|72.66.115.13|) as DNS server in network adapter settings (found this solution here https://serverfault.com/questions/776049/how-to-simulate-dns-server-response-timeout ).

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
connect attempt.

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?

Angus

--
A.S.

--
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

Reply via email to