Apollo: TopologyManager for source code analysis

There is an important part in cyber called service discovery && topology management , and its main implementation cyber/service_discovery/is as follows . Data paths are established between nodes through the read and write terminals. With the channel as the edge, a data flow network can be obtained in this way. The network is dynamic as nodes may exit and subscriptions may change. Therefore, it is necessary to monitor this topology network.

The data structure mainly responsible for this is TopologyManager, which is defined in cyber\service_discovery\topology_manager.h

insert image description here
It is a singleton, because each process only needs one to be responsible for monitoring the network topology.

insert image description here
TopologyManager has three sub-managers, and has a common base class Manager. They are:

  • NodeManager is used to manage nodes in the network topology.
  • ChannelManager is used to manage channels, that is, edges in the network topology.
  • ServiceManager is used to manage Service and Client.

There are two levels of topology change monitoring in Cyber ​​RT:

  • Discovery mechanism based on Fast RTPS :

    • It mainly monitors whether participants in the network join or exit
      • When the TopologyManager::CreateParticipant() function creates a transport::Participant object, it will enter a name that includes the host name and process id.
      • ParticipantListener is used to monitor network changes.
        • When the network topology changes, Fast RTPS uploads ParticipantDiscoveryInfo, and converts the information into the data structure in Cyber ​​RT in the TopologyManager::Convert() function TopologyManager::Convert()
        • Then call the callback function TopologyManager::OnParticipantChange(), which will call the OnTopoModuleLeave() function of several other resource managers. Then the corresponding maintenance information can be updated in the sub-manager (such as deleting the corresponding node in the NodeManager).
    • This layer of topology monitoring is mainly through the automatic discovery mechanism provided by Fast RTPS. If the process exits unexpectedly, the corresponding information in each management must be updated. Its advantage is that it can work if the process goes wrong or the device is disconnected, but the granularity is relatively coarse and it is not very timely (such as when disconnected).
  • Proactive based topology change broadcast :

    • This part is mainly created and initialized in the TopologyManager::Init() function.
      • During initialization, their StartDiscovery() function will be called to start the automatic discovery mechanism.
      • Based on the RtpsParticipant object in the TopologyManager, these sub-managers will create corresponding subscribers and publishers through CreateSubscriber() and CreatePublisher().
      • The channel names in the sub-manager are node_change_broadcast, channel_change_broadcast and service_change_broadcast respectively. Subscriber's callback function is Manager::OnRemoteChange(). The callback function will parse the topology change message and call the Dispose() function for processing.
    • This layer of topology monitoring is active, which needs to be triggered by actively calling Join() and Leave() in the corresponding place, and then the callback function in each sub-manager updates the information.
      • For example, NodeManager::Join() will be called when NodeChannelImpl is created. When the Reader and Writer are initialized, the JoinTheTopolicy() function is called, and then the ChannelManager::Join() function is called.
      • Correspondingly, there is a LeaveTheTopology() function that means to leave the topology network. In these two functions, the Dispose() function will be called, and this function is a virtual function, which has its own implementation in each sub-manager. In addition, the Manager provides the AddChangeListener() function to register a callback function when the topology changes. For example, the Reader::JoinTheTopology() function will register the callback Reader::OnChannelChange() through this function.

data member

Guess you like

Origin blog.csdn.net/zhizhengguan/article/details/129433600