Hi Vyom On Wed, 28 Aug 2019 at 08:26, Vyom Tewari26 <vtewa...@in.ibm.com> wrote: > > Hi Milan, > > If i am reading code correctly then for each retry you are doubling the > retryTimeout(int retryTimeout = (timeout * (1 << retry));) which is right > retry strategy, So the timeout set to TCP instance is already double with > original timeout and it will keep doubling with each retry.
Check out how DnsClient::doUdpQuery() works. It reduces "timeoutLeft" after each UDP packed received. This ensures doUdpQuery() method does not block more than "pktTimeout". I did the same for TCP. Method DnsClient::continueTcpQuery() performs Socket::read() 3 times in a row. Note that Socket::setSoTimeout() applies to each read() operation individually. This means it is possible that each read() blocks for less than the specified timeout (hence it will not throw), but in total continueTcpQuery() method could block almost 3 times the value initially set via Socket::setSoTimeout(). > > The "continueTcpQuery" method is getting called from other places as well. Yes, from whatever code path it may have been called, it has the very same problem with not respecting DnsClient::timeout. -- Milan Mimica
