Hi Juhamatti, See below. > -----Original Message----- > From: juham...@gmail.com <juham...@gmail.com> > Sent: October 11, 2018 1:00 AM > To: tipc-discussion@lists.sourceforge.net > Subject: [tipc-discussion] TIPC scalability viewpoints > > Hello, > > I have bumped into views that TIPC would not scale for more than hundreds > of sockets due to the discovery part of the protocol itself.
There is no such limitation. In our own live clusters we are seeing tens of thousands of sockets, -per node. The neighbor discovery protocol has nothing to do with sockets, but nodes. How far our cluster scales is dependent of traffic and environment. In our live systems we are running ~75 nodes, but we have tested up to 800 node clusters, using the "Overlapping Ring Monitoring" algorithm, which kicks in at a cluster size of >32 nodes. The binding table and topology (service tracking) service handle sockets, that is true, but they are fully capable of handling the amount of sockets we are seeing in our systems. > From TIPC specs I > cannot really find any support for that claim, however removing zone- > handling may cause all clusters to be pushed into same zone. Despite what the specification used to claim, there was in reality never any multi-cluster or multi-zone support. By manipulating zone number, cluster number or network identity (now called cluster identity) one could create multiple clusters on the same network, but those always remained isolated islands, in the sense that it was impossible to establish TIPC links between the different clusters. Users were (and are) encouraged to use TCP instead. With the new addressing scheme we have discussed the option of letting individual nodes become member of two or more clusters, and hence potentially act as "routers" between those. This is fully possible, and probably not very difficult to do. So the day such a requirement arrives we will consider it. > Also, I guess > the service discovery and liveliness polling between the clusters could be a > problem too, if the clusters cannot be fully detached in reality. As I am not > really aware of the internals of the TIPC implementation, any clarifications > available for this subject? As said, there is no inter cluster communication, so this is not an issue. The probing/neighbor monitoring between nodes within the *same* cluster was an issue al long as we were using full-mesh (all-to-all) neighbor supervision, but this problem has been substantially mitigated by the monitoring scheme mentioned above. BR ///jon > > Thanks, > -- > Juhamatti > > _______________________________________________ > tipc-discussion mailing list > tipc-discussion@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tipc-discussion _______________________________________________ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
