add text to markdown table headers, fix some return types, fix emane link

This commit is contained in:
Huy Pham 2019-09-17 09:33:55 -07:00
parent 463d4d145e
commit 22189122e6
5 changed files with 31 additions and 47 deletions

View file

@ -115,7 +115,7 @@ class NodeBase(object):
:param bool sort: boolean used to determine if interfaces should be sorted
:return: network interfaces
:rtype: list
:rtype: list[core.nodes.interfaces.CoreInterface]
"""
if sort:
return [self._netif[x] for x in sorted(self._netif)]
@ -210,7 +210,7 @@ class NodeBase(object):
:param flags: message flags
:return: list of link data
:rtype: [core.data.LinkData]
:rtype: list[core.data.LinkData]
"""
return []
@ -308,7 +308,7 @@ class CoreNodeBase(NodeBase):
:param int ifindex: interface of index to attach
:param core.nodes.interface.CoreInterface net: network to attach
:return:
:return: nothing
"""
if ifindex not in self._netif:
raise ValueError("ifindex %s does not exist" % ifindex)
@ -1112,7 +1112,7 @@ class CoreNetworkBase(NodeBase):
:param int flags: message type
:return: list of link data
:rtype: [core.data.LinkData]
:rtype: list[core.data.LinkData]
"""
all_links = []

View file

@ -9,7 +9,7 @@ The Extendable Mobile Ad-hoc Network Emulator (EMANE) allows heterogeneous netwo
EMANE is developed by U.S. Naval Research Labs (NRL) Code 5522 and Adjacent Link LLC, who maintain these websites:
* <http://www.nrl.navy.mil/itd/ncs/products/emane>
* <https://github.com/adjacentlink/emane>
* <http://www.adjacentlink.com/>
Instead of building Linux Ethernet bridging networks with CORE, higher-fidelity wireless networks can be emulated using EMANE bound to virtual devices. CORE emulates layers 3 and above (network, session, application) with its virtual network stacks and process space for protocols and applications, while EMANE emulates layers 1 and 2 (physical and data link) using its pluggable PHY and MAC models.

View file

@ -7,30 +7,14 @@
The top question about the performance of CORE is often *how many nodes can it handle?* The answer depends on several factors:
<table>
<tbody>
<tr>
<td>Hardware</td>
<td>the number and speed of processors in the computer, the available processor cache, RAM memory, and front-side bus speed may greatly affect overall performance.</td>
</tr>
<tr>
<td>Operating system version</td>
<td>distribution of Linux and the specific kernel versions used will affect overall performance.</td>
</tr>
<tr>
<td>Active processes</td>
<td>all nodes share the same CPU resources, so if one or more nodes is performing a CPU-intensive task, overall performance will suffer.</td>
</tr>
<tr>
<td>Network traffic</td>
<td>the more packets that are sent around the virtual network increases the amount of CPU usage.</td>
</tr>
<tr>
<td>GUI usage</td>
<td>widgets that run periodically, mobility scenarios, and other GUI interactions generally consume CPU cycles that may be needed for emulation.</td>
</tr>
</tbody>
</table>
| Factor | How that factor might affect performance |
|---|---|
| Hardware | the number and speed of processors in the computer, the available processor cache, RAM memory, and front-side bus speed may greatly affect overall performance. |
| Operating system version | distribution of Linux and the specific kernel versions used will affect overall performance. |
| Active processes | all nodes share the same CPU resources, so if one or more nodes is performing a CPU-intensive task, overall performance will suffer. |
| Network traffic | the more packets that are sent around the virtual network increases the amount of CPU usage. |
| GUI usage | widgets that run periodically, mobility scenarios, and other GUI interactions generally consume CPU cycles that may be needed for emulation. |
On a typical single-CPU Xeon 3.0GHz server machine with 2GB RAM running Linux, we have found it reasonable to run 30-75 nodes running OSPFv2 and OSPFv3 routing. On this hardware CORE can instantiate 100 or more nodes, but at that point it becomes critical as to what each of the nodes is doing.

View file

@ -24,7 +24,7 @@ shutdown commands, and meta-data associated with a node.
Here are the default node types and their services:
|||
| Node type | Services |
|---|---|
| *router* | zebra, OSFPv2, OSPFv3, and IPForward services for IGP link-state routing. |
| *host* | DefaultRoute and SSH services, representing an SSH server having a default route when connected directly to a router. |

View file

@ -74,7 +74,7 @@ When CORE is in Edit mode (the default), the vertical Editing Toolbar exists on
* ![alt text](../gui/icons/tiny/link.gif) *Link* - the Link Tool allows network links to be drawn between two nodes by clicking and dragging the mouse
* ![alt text](../gui/icons/tiny/router.gif) *Network-layer virtual nodes consist of the following:*
|||
| Network-layer node | Description |
|---|---|
| ![alt text](../gui/icons/tiny/router.gif) *Router* | runs Quagga OSPFv2 and OSPFv3 routing to forward packets. |
| ![alt text](../gui/icons/tiny/host.gif) *Host* | emulated server machine having a default route, runs SSH server. |
@ -84,7 +84,7 @@ When CORE is in Edit mode (the default), the vertical Editing Toolbar exists on
| ![alt text](../gui/icons/tiny/document-properties.gif) *Edit* | edit node types button invokes the CORE Node Types dialog. New types of nodes may be created having different icons and names. The default services that are started with each node type can be changed here. |
* ![alt text](../gui/icons/tiny/hub.gif) *Link-layer nodes consist of the following:*
|||
| Link-layer node | Description |
|---|---|
| ![alt text](../gui/icons/tiny/hub.gif) *Hub* | the Ethernet hub forwards incoming packets to every connected node. |
| ![alt text](../gui/icons/tiny/lanswitch.gif) *Switch* | the Ethernet switch intelligently forwards incoming packets to attached hosts using an Ethernet address hash table. |
@ -94,18 +94,18 @@ When CORE is in Edit mode (the default), the vertical Editing Toolbar exists on
* *Annotation Tools*
|||
| Tool | Functionality |
|---|---|
| ![alt text](../gui/icons/tiny/marker.gif) *Marker* - for drawing marks on the canvas. |
| ![alt text](../gui/icons/tiny/oval.gif) *Oval* - for drawing circles on the canvas that appear in the background. |
| ![alt text](../gui/icons/tiny/rectangle.gif) *Rectangle* - for drawing rectangles on the canvas that appear in the background. |
| ![alt text](../gui/icons/tiny/text.gif) *Text* - for placing text captions on the canvas. |
| ![alt text](../gui/icons/tiny/marker.gif) *Marker* | for drawing marks on the canvas. |
| ![alt text](../gui/icons/tiny/oval.gif) *Oval* | for drawing circles on the canvas that appear in the background. |
| ![alt text](../gui/icons/tiny/rectangle.gif) *Rectangle* | for drawing rectangles on the canvas that appear in the background. |
| ![alt text](../gui/icons/tiny/text.gif) *Text* | for placing text captions on the canvas. |
### Execution Toolbar
When the Start button is pressed, CORE switches to Execute mode, and the Edit toolbar on the left of the CORE window is replaced with the Execution toolbar Below are the items on this toolbar, starting from the top.
|||
| Tool | Functionality |
|---|---|
| ![alt text](../gui/icons/tiny/select.gif) *Selection Tool* | in Execute mode, the Selection Tool can be used for moving nodes around the canvas, and double-clicking on a node will open a shell window for that node; right-clicking on a node invokes a pop-up menu of run-time options for that node. |
| ![alt text](../gui/icons/tiny/stop.gif) *Stop button* | stops Execute mode, terminates the emulation, returns CORE to edit mode. |
@ -126,7 +126,7 @@ menu, by clicking the dashed line at the top.
The File menu contains options for manipulating the **.imn** Configuration Files. Generally, these menu items should not be used in
Execute mode.
|||
| Option | Functionality |
|---|---|
| *New* |this starts a new file with an empty canvas. |
| *Open* | invokes the File Open dialog box for selecting a new **.imn** or XML file to open. You can change the default path used for this dialog in the Preferences Dialog. |
@ -144,7 +144,7 @@ Execute mode.
### Edit Menu
|||
| Option | Functionality |
|---|---|
| *Undo* | attempts to undo the last edit in edit mode. |
| *Redo* | attempts to redo an edit that has been undone. |
@ -159,7 +159,7 @@ Execute mode.
The canvas menu provides commands for adding, removing, changing, and switching to different editing canvases.
|||
| Option | Functionality |
|---|---|
| *New* | creates a new empty canvas at the right of all existing canvases. |
| *Manage...* | invokes the *Manage Canvases* dialog box, where canvases may be renamed and reordered, and you can easily switch to one of the canvases by selecting it. |
@ -173,7 +173,7 @@ The canvas menu provides commands for adding, removing, changing, and switching
The View menu features items for controlling what is displayed on the drawing
canvas.
|||
| Option | Functionality |
|---|---|
| *Show* | opens a submenu of items that can be displayed or hidden, such as interface names, addresses, and labels. Use these options to help declutter the display. These options are generally saved in the topology files, so scenarios have a more consistent look when copied from one computer to another. |
| *Show hidden nodes* | reveal nodes that have been hidden. Nodes are hidden by selecting one or more nodes, right-clicking one and choosing *hide*. |
@ -186,7 +186,7 @@ canvas.
The tools menu lists different utility functions.
|||
| Option | Functionality |
|---|---|
| *Autorearrange all* |automatically arranges all nodes on the canvas. Nodes having a greater number of links are moved to the center. This mode can continue to run while placing nodes. To turn off this autorearrange mode, click on a blank area of the canvas with the select tool, or choose this menu option again. |
| *Autorearrange selected* | automatically arranges the selected nodes on the canvas. |
@ -200,7 +200,7 @@ The tools menu lists different utility functions.
| *Topology generator* | opens a submenu of topologies to generate. You can first select the type of node that the topology should consist of, or routers will be chosen by default. Nodes may be randomly placed, aligned in grids, or various other topology patterns. All of the supported patterns are listed in the table below. |
| *Debugger...* | opens the CORE Debugger window for executing arbitrary Tcl/Tk commands. |
| |Different topology patterns|
| Pattern | Description |
|---|---|
| *Random* | nodes are randomly placed about the canvas, but are not linked together. This can be used in conjunction with a WLAN node to quickly create a wireless network. |
| *Grid* | nodes are placed in horizontal rows starting in the upper-left corner, evenly spaced to the right; nodes are not linked to each other. |
@ -269,7 +269,7 @@ The Session Menu has entries for starting, stopping, and managing sessions,
in addition to global options such as node types, comments, hooks, servers,
and options.
|||
| Option | Functionality |
|---|---|
| *Start* or *Stop* | this starts or stops the emulation, performing the same function as the green Start or red Stop button. |
| *Change sessions...* | invokes the CORE Sessions dialog box containing a list of active CORE sessions in the daemon. Basic session information such as name, node count, start time, and a thumbnail are displayed. This dialog allows connecting to different sessions, shutting them down, or starting a new session. |
@ -281,7 +281,7 @@ and options.
| *Change Sessions...* | invokes the Sessions dialog for switching between different running sessions. This dialog is presented during startup when one or more sessions are already running. |
| *Options...* | presents per-session options, such as the IPv4 prefix to be used, if any, for a control network the ability to preserve the session directory; and an on/off switch for SDT3D support. |
| |Session states|
| Session state | Description |
|---|---|
| *definition* | used by the GUI to tell the backend to clear any state. |
| *configuration* | when the user presses the *Start* button, node, link, and other configuration data is sent to the backend. This state is also reached when the user customizes a service. |
@ -660,7 +660,7 @@ that CORE will create.
In version 1.0, the XML file is also referred to as the Scenario Plan. The Scenario Plan will be logically
made up of the following:
|||
| Plan | Description |
|---|---|
| **Network Plan** | describes nodes. hosts, interfaces, and the networks to which they belong. |
| **Motion Plan** | describes position and motion patterns for nodes in an emulation. |