Appendix E
An introduction to the cnet network simulator
cnet is a network simulator which enables experimentation with various data-link layer, network layer, routing
and transport layer networking protocols in networks consisting of any combination of point-to-point links and
IEEE 802.3 Ethernet segments. 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. In
addition, advanced users may develop different Application and Physical Layers which exhibit varying
statistical characteristics of message generation and data transmission. Simulation sizes may range from two to
a few hundred nodes.
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.
Appendix E
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-andwait 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.
Appendix E
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).
Appendix E
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
Appendix E
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.
Appendix E
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.
Appendix E
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.
Appendix E
And when you believe that you have your protocols working, run them with cnet's -r option to generate a
random, connected, topology.