[squid-users] How to "active" update NetDB informations ?

Grant Taylor gtaylor at tnetconsulting.net
Fri Jul 1 20:38:48 UTC 2022


On 7/1/22 8:22 AM, Théo BARRAGUE wrote:
> If *link a* slows down, the RTT will increase and *squid* will send all 
> requests to *squid b* because his RTT is low.
> But, if *link a* come back and with a lower RTT than *squid b*, *squid 
> a* will never know because no requests are made to him until RTT on 
> *squid b* goes up ( upper than the "uppest" / "oldest" RTT of *squid a* ).
> 
> How to deal with this scenario ?

I have no idea if this will help you or not but this problem seems 
reminiscent of DNS servers (e.g. BIND/named) deal with multiple 
potential servers.

My loose understanding is that BIND/named will /artificially/ alter the 
cached RTT /explicitly/ to make sure that abnormally high / low values 
don't negatively impact things.  I think there are a couple of ways to 
do this:

1)  Artificially decrease the RTT incrementally or based on it's age 
(last seen) so that an originally high RTT value lowers enough that it 
becomes a candidate to be used again.  --  If it turns out that the RTT 
still really is high then the RTT will get updated back to it's high 
value and thus depreffed.

2)  Artificially increase the RTT incrementally, perhaps one point per 
test, so that the originally low RTT value raises enough that is higher 
than the other candidate, thus deprefed.

This turns into a balancing game, artificially adjust the RTT so that a 
system is (not) chosen thereby choosing the other system, which updates 
the values.

I think which method is used is probably based on what works best in the 
code.

But one of these should cause some small portion of traffic to go to the 
deprefed server explicitly to keep it's RTT up to date.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20220701/2c6ad551/attachment.bin>


More information about the squid-users mailing list