Closed theodorelu27 closed 3 years ago
@alyhasansakr still a mess, but all planned features has been implemented
@alyhasansakr I've implemented the EQR Change queueing and management runner but I just realized that after disconnecting, while disconnect seems to work as intended, the get node would still provide the last provided IP, so in the client side, it would try to connect and ended up with a bad evaluation and another disconnect
@alyhasansakr yeah, I just realized that it would be applied quite differently from what I initially expected I've changed the EQR increment generation to a fixed time according to the last recorded latency as we discussed but as EQR is reported using the latency reporter, the faster change of the EQR (now updated every 10ms) will not be reflected on smaller EQR, is that okay?
{"timestamp":"2021-04-21_11:43:44","latency":122,"use_server":false,"server_ip":null,"evaluating":false,"eqr":0}
{"timestamp":"2021-04-21_11:43:45","latency":93,"use_server":false,"server_ip":null,"evaluating":false,"eqr":0}
{"timestamp":"2021-04-21_11:43:46","latency":197,"use_server":false,"server_ip":"172.17.0.3","evaluating":true,"eqr":5}
{"timestamp":"2021-04-21_11:43:48","latency":102,"use_server":false,"server_ip":"172.17.0.3","evaluating":true,"eqr":10}
{"timestamp":"2021-04-21_11:43:49","latency":448,"use_server":true,"server_ip":"172.17.0.3","evaluating":false,"eqr":10}
{"timestamp":"2021-04-21_11:43:51","latency":513,"use_server":true,"server_ip":"172.17.0.3","evaluating":false,"eqr":10}
@theodorelu27 That is ok, actually the speed at which the EQR updates is inversely proportional to the max EQR. Now that we change it every 10ms we should have a higher max EQR. For that max EQR should be configurable.
Implementation for #98 with fixed max EQR, evaluating state, and disconnect client when EQR is not satisfactory