Client: Visualizing Overlay Network

[kevin-w-du]

Priority: LOW

In many cases, we will deploy an overlay network on top of the emulator (such as DNS infrastructure, Botnet, Darknet, Blockchain). I hope to have an option to only display this overlay network. Here are my thoughts (I am using DNS as an example):

• Initially, everything will be displayed (just like what the current client program does).
• When we click the DNS button, we will change the colors of the nodes in the diagram (the topology of the diagram will not change, the shapes will stay the same, only the color of each node will change).
• We will use one color for each type of the DNS nodes (root, TLD, and domain servers).
• Nodes that do not belong to the DNS infrastructure will be grayed out.

The question is how the client program know which node is DNS node, of what type. Do we need to provide some visualization-related information when building the emulator, so we can help the client program?

[magicnat]

We should consider adding a set of API, probably on the Node (routers, hosts) and Network class (internal networks, internet exchanges), for layers, services, or just the emulation itself, to interact/integrate the client UI.

Related: #21.

[kevin-w-du]

For each node, such as Internet Exchange, Network, host, etc. please add a new attribute to these classes, called displayName. This name will only be used in the visualization. Their internal name such as ix100 should not change. When we display a node, if a node's displayName is not empty, we will use this name to display. If it is empty, we will use the node's internal name. This way, we can give each node a meaningful name. For example, we can call an Internet Exchange "Manhattan" to represent the real "Manhattan internet exchange" in the real world.

[amdfxlucas]

@kevin-w-du , @magicnat I made some experience with overlay-network visualisation myself.

What I did is :

• deploy overlay-multicast peers on endhosts
• mount a shared volume into all node containers, as well as the seedemu-client
• deploy an audit application in the seedemu-client container that
  • creates a unix domain socket in the shared volume where it listens for incoming audit-events from nodes in the overlay
  • echos any events through a websocket into the browser
• hack the seedemu-client web app to read and analyse the audit events from the websocket and add of remove edges in the Graph accordingly

What I learned:

• I should have done more preprocessing in the audit-application, instead of simply echoing the events such as:
  • translation from peer-IDs to 12-digit docker-container-IDs used as vertex IDs in the graph
  • bookkeeping of which edges i already added/removed (and in which direction ,as i need arrowheads to be displayed correctly )

Proposal

There should be a number of specified events/messages that the client understands such as:

• manipulation of direct edges
  • AddEdge{topic, from, to, options{...}}
  • UpdateEdge{topic, from,to, new_options{...} }
  • RemoveEdge{topic, from,to}
  • manipulation of 'paths' (overlay edges mapped to the underlay)
    • AddPath{from, to , topic, ip_traceroute{ underlay hops.. } }
    • RemovePath{..}
    • UpdatePath{..} Which could be used by all sorts of different service instances in the simulation.

Here the topic would allow the webapp to distinguish to which of the potentially many overlays an event relates. The webapp could use the topics as a filter to hide/unhide overlays.