This relies on default settings of tcp tuning values set in system.
I like the change in 50adf82199c362da6c542f1d22be2eeab7481211 adding
timeout variable check.
But using SO_SNDTIMEO would allow setting it in time units, regardless
default tcp values. And should be supported also on BSD and in general
more portable variant. Do you have a reason to use only linux-specific
variant? 2 tries seems too little if 6 is the default. I wish we had
some value to tell system just retry (a bit) faster than usual. Haven't
found that. I would use 3-4 to overcome short connection break at least.
20-30 seconds should be better default value.
I think the final fix would be making connections non-blocking and in
parallel, accepting first reply which arrives. This is just small tuning
to be not so terrible. It has to be sooner than alarm kills the TCP
client, at least 3 servers should be tried before that happens. I think
previous default allowed just one, so my changed server report over pipe
did not happen.
I am also not sure we should log every truncated packet without some
limit. I think it might lead to denial of service attack. Just stats
counter should be incremented, which can be watched by polling. Number
of accepted TCP connections is not counted if I see well. As is not
number of truncated messages. Would be useful for the service monitoring.
On 26. 05. 23 18:53, Simon Kelley wrote:
Setting TCP_SYNCNT to 2 limits the delay for a non responsive address
to about 8 seconds, which is mouch more sensible.
Simon.
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
