Physical Topology Module

[nickmame]

Here's a proposal for the topology module we discussed at our last meeting. I am assuming that it will be a proper module that schedules itself with the broker and communicates with other modules through ptrees / protocol buffers. Feedback please.

The storage for the module would be:

map<string, set<string> > vertex_to_adjacency_list
multimap<string, pair<string,string> > fid_to_edge

The main function that would be executed each phase:

foreach fid in fid_to_edge
    let (u,v) be the pair fid_to_edge[fid]
    if fid is open     
         remove u from vertex_to_adjacency_list[v]
         remove v from vertex_to_adjacency_list[u]
    else
        add u to vertex_to_adjacency_list[v]
        add v to vertex_to_adjacency_list[u]

The sole read handler would be:

HandleRequest( string module, string target, int width = -1 )
    perform a breadth first search rooted at target with a maximum depth of width
    foreach vertex v in the breadth first search result
         result[v] = vertex_to_adjacency_list[v]
    return result to module

This module would be used to find subgraphs of connected components in the physical network topology. This is sufficient for both group management (with no width restriction) and physical attestation (with width = 2).

The fid_to_edge variable is a multimap in case one FID for some reason has control over multiple edges in the graph. The identifiers for the vertices would be the hostnames of the DGI.

The input file would resemble:

 edge a b
 edge b c
 edge c a
 sst a raichu.freedm
 sst b manectric.freedm
 sst c galvantula.freedm
 fid a b FID1
 fid b c FID2
 fid c a FID3

The use of temporary tokens (a, b, c) for the vertices makes it harder than necessary to parse this input file. However, it would be a complete pain to handle configurations between different universities if you had to change the hostnames in more than one place in this file. With this format, it's harder for someone to corrupt the input file.

[nickmame]

As a side note: it makes more sense for this to be a singleton than a module to me, but that's assuming that we don't later extend it into something more elaborate.

[mcatanzaro]

On Fri, 2014-02-28 at 17:49 -0800, Thomas Roth wrote:

let (u,v) be the pair fid_to_edge[fid]

Should be a foreach, since it's a multimap not a map, but otherwise this makes sense.

[mcatanzaro]

On Fri, 2014-02-28 at 17:49 -0800, Thomas Roth wrote:

The use of temporary tokens (a, b, c) for the vertices makes it harder than necessary to parse this input file. However, it would be a complete pain to handle configurations between different universities if you had to change the hostnames in more than one place in this file. With this format, it's harder for someone to corrupt the input file.

I understand your point, but that makes doing simple things unnecessarily confusing, especially when we get to 30-node systems. I think it's best to stick with hostnames....

[mcatanzaro]

On Fri, 2014-02-28 at 17:56 -0800, Thomas Roth wrote:

As a side note: it makes more sense for this to be a singleton than a module to me, but that's assuming that we don't later extend it into something more elaborate.

I've been thinking about this and I'd lean towards non-module as well, but let's chat on Monday.

[nickmame]

Stephen done it.