An introduction to the cnet network simulator

cnet either displays the entire network under Tcl/Tk or runs rather less visually on an ASCII terminal. Under Tcl/Tk, cnet provides a graphical representation of the network under execution and permits a number of attributes of the network to be modified while the simulation is running. Nodes may be selected with the mouse to reveal a sub-window displaying the output and protocol statistics of that node. Some of the node's attributes, such as message generation rates and sizes, may be modified while the network is running by selecting choice buttons. Similarly, the default attributes of all nodes in the network may be simultaneously modified by selecting and changing global attributes. From another menu, each node may be forced to reboot, (impolitely) crash, (politely) shutdown and reboot, pause and (hardware) fail.

This is a typical starting representation of a two node simulation, here implementing the stop-and-wait protocol. The simulation is currently running but we could pause and then single-step through our protocol using the buttons. A total of 82292 messages have been delivered so far, and the Application Layer has not been presented with any ``incorrect'' messages. Our protocol is thus reported as being 100% correct.

Here we've clicked on one of the nodes to display its output window. All output on each node's output window is generated by calling C's printf() function in the protocol code. Here we see an annotation of the stop-and-wait protocol. The text on the first of the five central buttons has also been defined by the protocol code. If this button is selected, execution will transfer to code provided by the student's code, perhaps for debugging. An output window is available for each node, even in large simulations.

Selecting a link results in a sub-window being displayed which shows transmission statistics for that link. Links are bidirectional, so ``selecting a link'' means clicking on the link close to its source node. The link-based attributes of transmission costs and error probabilities may be modified while the network is running by dragging sliders. Similarly, the attributes of all links in the network may be simultaneously modified by selecting and changing global link attributes.

cnet is able to automatically detect and report a wide variety of errors commonly made by undergraduate 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. As shown in the following image, errors are reported in a popup-window describing the error and its location in the student's source code (here, the previous line has deliberately caused the error, and by calling CHECK we detect and report the ill-effect).

cnet can present a limited visualization of data frames traversing the Physical Layer. Using simple rectangles, colours, and short strings, it is possible to display both data and acknowledgment frames, and the contents of some of their fields. In combination, these features may be used to debug implementations of Data Link Layer protocols. Below, we see a selective-repeat protocol experiencing frame loss (the upper ghostly white data frame number 5) and frame corruption (the singed grey data frame number 3), while other data and acknowledgment frames are also being exchanged.

cnet requires network protocols to be written in the ANSI-C programming language and supports their execution within a single UNIX or Linux process. A standard compiler, preferably gcc, is used to compile the user-written protocol code. The compiled code is then dynamically linked at run-time with the cnet simulator. Protocols are invoked directly by cnet itself - they are not interpreted. By design, the protocols do not need to contain any windowing code.

As of version 2.0, cnet supports IEEE 802.3 Ethernet segments as well as its traditional point-to-point WAN links. Each segment consists of two or more Network Interface Cards (NICs) that connect host or router nodes to the segment. Large networks may be constructed by joining multiple Ethernet segments via gateway nodes and wide-area point-to-point links. Each NIC's own address is initially defined in the topology file, in the 6-byte hexadecimal format of traditional Ethernets, and cnet provides functions to configure each NIC's address, and to set a NIC into promiscuous mode. The simulation of Ethernets is reasonable, but not perfect. cnet supports a fixed transmission rate of 10Mbps, a slot-time of 52usecs, broadcast addressing, collision detection, jamming, and binary exponential backoff, but does not support jitter control nor multicast addressing.

The current values of the node and link attributes (as possibly modified via the windowing interface) are available to the protocol code each node in C data structures and variables. These structures and variables are declared in cnet's header file <cnet.h>, which is included in each node's protocol code. These structures and variables are initialized when each node is rebooted and updated as each node is scheduled for execution. Their values are considered as read-only and cannot be (successfully) modified directly by the protocols. They may, of course, be modified via the windowing interface.

Costs or weights may be assigned to each link, to represent the cost of transmitting each frame, or the number of bytes in each frame. Protocols may then be developed to deliver network traffic which either minimize the total cost, or maximize the total flow.

And when you believe that you have your protocols working, run them with cnet's -r option to generate a random, connected, topology.