# EmuCD: An Emulator for Content Dissemination Protocols in Vehicular Networks
## 3 EmuCD Architecture
It is the software's responsibility to perform tasks such as neighbour discovery (using UDP broadcasts, network pings, etc.) or data management, as the emulator does not provide any support. As a rule of thumb: if the software/protocol can run in real hardware, it is ready to run in the emulator. This is the first time that a protocol can be tested in an emulated VANET without any modifications to the protocol itself: all that is required is a data trace, the software to be tested and the edition of some configuration files in the emulator. An overall view of the architecture and its components is available in Figure 1. The nodes are Docker containers, with each one running a daemon and being controlled by a single manager. Ubuntu 16.04 is the base of the image, so each node can be considered to be a full OS with its own routing tables, network interfaces and storage. The manager is decoupled from the nodes in a way that allows for multiple managers to exist in an emulation. For example, each manager coordinating a different set of containers in separate hardware, in order to better emulate realistic conditions. The coordination between all nodes is done by this component, as it is responsible for:  
* Loading the emulation's parameters from a JSON file;
* Starting the emulation;
* Waiting for each container to be \"booted\" and ready;
* Synchronizing every container;
* Building the emulation log file;
* Providing data for the dashboard (nodes' positions, content distribution progress, content distribution metrics);
* Polling the current status from each container's daemon;
* Collecting and storing content distribution metrics. Each node is running a daemon process. The main task of the daemon is to update the node's IP routing table according to the neighbours in a given instant. In order to do this, two important pieces of information are required: the current node's neighbours and their IP addresses. The neighbours are read from the dataset (stored in a file), for the relevant node at the current timestamp. These node IDs are then converted into the respective container's IP. If for example one of the neighbours is the node with ID 332, its container's IP address is 172.20.3.32, so an entry in the routing table is added by running the command \"ip route add 172.20.3.32 dev \(\$\)IF\". The dataset must be available prior to the emulation start, as it is included in the Docker image when being built. It consists of several files, one per node, with each file containing several entries. An entry is represented by a timestamp, latitude, longitude and a list of neighbours in the format of (nodeID, Received Signal Strength Indication (RSSI)) tuples. A node is only considered to be a neighbour if its RSSI meets a configurable threshold. Although the manager and daemon are the core of the EmuCD emulator, a web dashboard was created to assist with the visualization of the emulator's status and progress. It periodically polls the /status endpoint of the manager to display the positions of every node in a map, as well as the progress per node of the content's distribution. The dashboard can also show an overview of the metrics collected, like the cumulative download progress, the number of OBUs that reached 100% in each timestamp, or the average download progress across all OBUs.