Yakov, ARC_ID approach seems just a variation of node attribute based ordering for me.
I suggest more generic approach. What if we define node ordering using something like NodeComparator? Then a new node joins topology, it calculates node for joining using sorting on current topology + new node. nextNode just takes first element in sorted list. It's guaranteed what all nodes will return the same sorted list for the topology version. We can provide default implementation based on IP address: nodes on the same host : nodes on the same subnet : other nodes I think this will work for most cases. If needed user can provide it's own comparison strategy based on latencies, data centers, whatever. 2016-12-26 17:17 GMT+03:00 Александр Меньшиков <sharple...@gmail.com>: > > 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 > > > > > > -- Best regards, Alexei Scherbakov
