The CONFINE monitoring system also includes a special kind of metrics that allows us to have an idea of the topology of the nodes that are part of the Confine network. This network topology metric is useful to understand the relationships between the different CONFINE nodes, that is, how the Research Devices are related to each other. Figure 14 shows the information displayed by the monitoring system after collecting the network topology metrics. We can observe the Controller node in yellow, the different RDs in green and other network nodes in light blue.
Figure 14: Network topology map
This new metric is extremely important for researchers that want to deploy experiments in CONFINE. By visualising the Network Topology, an experimenter can easily detect, for example, if all the Research Devices that he was going to select to run his experiments are connected to the same Community Device (CD). Running a experiment before checking this network map would've meant that the experimenter is not really taking advantage of the community networks that are part of CONFINE because all the selected RDs were directly connected to the same node. Figure 15 depicts an example of the Network Topology of nodes connected to the same CD.
Figure 15: Example of selection of RDs connected to the same CD
In order to determine the topology of the CONFINE network we add a Traceroute Pluggable Daemon to the monitoring clients located in the different RDs. Figure 16 shows how the RDs containing these daemons send traceroute packages every 60 seconds to the network node that hosts the CONFINE Controller. The Monitoring Server then receives all the traceroute messages from all the RDs belonging to the CONFINE network and responds accordingly.This way, all the Traceroute Daemons collect then information about the path from the specific RD to the Controller.
Figure 16: Traceroute pluggable daemon
The information collected by the Traceroute Daemons is saved in a JSON document and sent to the Monitoring Server to be stored at the database. These JSON files are the “Traceroute” type documents mentioned in the Server Specifics section. The content of these documents is depicted in Figure 17.
Figure 17: Traceroute metrics monitored by the server
As we can observe, the Traceroute document saved by every RD contains a “trace” or list of the nodes that are in the path from such RD to the Controller. For each node we have the following information:
For clarification, let consider a network composed by 6 nodes, where 1 of them is the Controller and only 2 of the others are RDs. Figure 18 shows an example of the list of nodes that each RD would return to the Monitoring Server.
Figure 18: Example of the trace information monitored by the RDs
As we can observe in the figure, each RD saves a list containing the hop sequence from such RD to the Controller. When the Monitoring Server located in the Controller performs monitoring tasks every 5 minutes, it collects this information in form of JSON documents and stores them in the Couchbase database. The Middleware component of the server then fetches the hop sequences for each RD from the database and converts them to direct neighbour relationships. According to the example in the figure, we miss information about node 5, but this fact is not a problem for us because we are only interested in having information about RDs and their relationships but we do not need to have a precise representation of the network topology.