RFR(s): 8228580: DnsClient TCP socket timeout

Milan Mimica milan.mimica at gmail.com
Fri Sep 6 10:40:04 UTC 2019

On Thu, 5 Sep 2019 at 18:59, Florian Weimer <fweimer at redhat.com> wrote:
> But I think in the UDP case, the client will retry.  I think the total
> timeout in the TCP case should equal the total timeout in the UDP case.
> That's what I'm going to implement for glibc.  The difference is that in
> the TCP case, the TCP stack will take care of the retries, not the
> application code.

I understand that, and it does make sense, but we have to put it in
context of how current DnsClient.java works:
            // The UDP retry strategy is to try the 1st server, and then
            // each server in order. If no answer, double the timeout
            // and try each server again.

Fallback to TCP happens within this process. Going immediately with
timeout*2^maxRetry could yield significantly larger delays, if there
happens to be some other server on the list that works better.
I would rather look into reusing TCP connections, not to close them immediately.

What about read() and non-handshake TCP retransmissions? Do those
usually happen faster?

Milan Mimica

More information about the core-libs-dev mailing list