Of course where is no need to sort all nodes. It's enough just to select smallest node.
2016-12-26 22:29 GMT+03:00 Alexei Scherbakov <alexey.scherbak...@gmail.com>: > 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 > -- Best regards, Alexei Scherbakov
