>> Vyacheslav, I agree that latency increase in the way you describe, but I still don't understand how we use this information in discovery. Latency may differ from time to time depending on many factors. I still think that arc approach is more intuitive for user and easier to implement. >>
Way of latency increase is just a main idea. I suggest to connect new node on some priority. General approach: -- if [ there are same host node ] then [ connect with it ] else if [ there are same subnet nodes] then [ connect with one of them ] // how to choose node from a set of subnet? - choose with min latency each other else [ connect to remote nodes ] // how to choose node from a set of remotes? - choose with min latency each other -- Maybe we can describe another intermediate steps. 2016-12-26 15:08 GMT+03:00 Yakov Zhdanov <yzhda...@apache.org>: > >> > I just want to understand which benefits we get when implement what we're > talking about. If major benefit is reduced latency of ring messages, then > the assignment 'ARC ID' in accordance with latency value is quite > enough. But if there are any hidden problems because of the large number of > reconnection (like I described in first message in this discussion), then > better to find a way to determine real physical location. > >> > > I suggest to solve ring building up and reducing number of reconnects > separately. If we have AxB-C-D-A then A will try to reconnect to B, then to > C, then to D. This is how discovery works now. I agree this should be fixed > and I have couple ideas on how we can do it but let's separate these ones. > > >> > Okey, then i think Vyacheslav's idea (using latency values) is quite enough > when we can't determine real physical location. > >> > > Can you please explain why this is better than arc approach? > > --Yakov >
