An introduction to the cnet network simulator

cnet is a network simulator enabling experimentation with various data-link layer, network layer, routing, and transport layer networking protocols in networks consisting of any combination of wide-area-networking (WAN), local-area-networking (LAN), or wireless-local-area-networking (WLAN) links. With reference to the OSI/ISO Networking Reference Model, cnet provides the Application and Physical layers. User-written protocols are required to "fill-in" any necessary internal layers and, in particular, to overcome the corrupted and lost frames that cnet's Physical Layer randomly introduces.

cnet protocols may be written in one-or-more source files, in either C or C++, and are compiled by cnet using your system's native compiler - clang on macOS, gcc on Linux. The compiled code is then dynamically linked with the simulator. Protocols are executed directly by cnet itself - they are not interpreted. By design, you do not need to compile the source-files yourself, and protocols do not need to provide any code for the GUI.

cnet either displays the entire network simulation 'map' with a GUI, or rather less visually on an ASCII terminal. Nodes may be selected with the mouse to display their 'terminal' output, generated by calling C's printf() function in the protocol code. By default, cnet executes the same code within every network node - all nodes share the same executable code, but each has its own variables. The only way for nodes to communicate is through the Physical Layer. Simulation sizes may range from two to a few hundred nodes. cnet schedules the execution of each node as 'events of interest' occur - a new message bring generated in the Application Layer, a frame arriving at the Physical Layer, a timer expiring...

compile = "stopandwait.c" icon = "macintosh" ber = 0.000005, winx = 500 winy = 300 mapwidth = 500px mapheight = 300px host Perth { x = 130px y = 130px messagerate = 1500ms } host Sydney { x = 380px y = 130px messagerate = 3500ms wan to Perth {} }

The image above shows a typical representation of a simple two node simulation, here implementing the stop-and-wait protocol under macOS. The simulation is currently running but we could pause and then single-step through the protocol. The text on the first of the five buttons has been set by the protocol code. If this button is clicked, execution will transfer to the protocol's code, perhaps for debugging. Each node has an output window, even in large simulations.

There are a number of ways to observe the progress, and possible problems, with developed protocols - including tracing the global event sequence, API calls made during an event-handler, API results, and an annotated timeline of events.

cnet is able to automatically detect and report a wide variety of errors commonly made by students when developing their protocols. These include invalid arguments passed to functions, an incorrect specification of links, addresses and timers, undetected message corruption or loss, messages passed to incorrect destinations, out-of-sequence or duplicated messages, etc. In the image above, a node with only a single physical link has attempted to transmit on link 2. Errors are reported in a popup-window describing the error and its location in the protocol's source code.

When a simulation contains only two nodes connected by a single link, cnet provides the Application and Physical layers and your protocol must implement a Data Link layer between the two provided layers. When simulations contain three or more nodes, at least one node will have multiple links, and routing decisions must be made by an additional Network or Routing layer. The image above shows a simulation with multiple nodes, each with a Network layer that manages a routing-table.

cnet supports mobile and wireless networking that may be configured to model IEEE 802.11 networks employing CSMA/CA protocols. Nodes and accesspoints may have one or more Network Interface Cards (NICs) whose attributes of transmission frequency and power, antenna gain, input sensitivity, and power consumption may all be specified in the topology file or modified using cnet's API. All wireless interfaces are, by default, modelled on (older) Orinoco PCMCIA Silver/Gold cards. Mobile nodes may move around the simulation map by determining and setting their current location, and may implement a variety of mobility models using cnet's consistent event-driven approach. Wireless signal propagation models that are aware of the same obstacles and physical environment observed by the mobility models, may also be implemented.