On Thu, 5 Sep 2019 at 18:59, Florian Weimer <fwei...@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
