> Can you please explain why this is better than arc approach? We had a misunderstanding. Everything okay with arc approach. But we must choose how nodes will determine "ARC_ID", and i think it can be calculated from latency values. If users will be able to set "ARC_ID" in config file then they can set different 'ARC_ID' on all nodes, and, in fact, point exact place in the ring, what we would like to avoid.
2016-12-26 15:36 GMT+03:00 Vyacheslav Daradur <daradu...@gmail.com>: > >> > 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 > > >
