Google

with various data-link layer, network layer, routing and transport layer networking protocols. It has been specifically developed for undergraduate teaching."> undergraduate, teaching"> TEXT ="black" LINK="blue" VLINK="purple">

An introduction to the cnet network simulator

cnet is a network simulator which enables experimentation with data-link, network (routing), transport and session layer protocols. 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.

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 protocol, 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.

As of version 1.7, cnet can present a limited visualization of data frames traversing the Physical Layer. Using just colours and lengths, 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. Here a selective-repeat protocol is experiencing frame loss (the ghostly white frame) and frame corruption (the singed grey frame).

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.

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.

line
cnet was written and is maintained by Chris McDonald (chris@cs.uwa.edu.au)