cnet v2.0.5

home
introduction
simulation model

topology files
cmdline options
the API

FAQ

download

The cnet simulation model

cnet supports a model of networking in which nodes are connected by either point-to-point links or Ethernet segments. Nodes may be either hosts or routers; introductory protocols will only use hosts and point-to-point links. Hosts are like workstations, with each having an Application Layer which generates messages for delivery to the Application Layers on other hosts. Hosts never generate messages for themself, and routers never generate messages at all.

The cnet simulation model appears in the following diagram:

Each node, from 2 to hundreds, is connected to other nodes by one or more physical point-to-point links or IEEE 802.3 Ethernet segments. Links are numbered within each node from 0 to the number of physical links that the node has. Link number 0 is always the node's LOOPBACK link, which simply delivers anything transmitted to it straight back to the same host. The first ``real'' link is number 1 and every node will have a link number 1. Each node's link attributes may be accessed, at runtime, via elements of the C structure variables linkinfo[1], linkinfo[2], and so on.

cnet itself provides each node with an Application Layer and a Physical Layer. In addition, a hidden Error Layer resides above the Physical Layer, and causes transmitted data frames to become corrupted or lost according to specified probabilities. Note that the standard OSI/ISO model does not provide an Error Layer!

Perhaps surprisingly, the nodes initially have very little knowledge of the network. Nodes do not know how many other nodes there are, what the other nodes are called, nor the attributes of any nodes or links other than their own. All inter-node communication necessary to learn this information must traverse the Physical Layer.

Protocol layers

cnet protocols are written from the point of view of each node, that is, we imagine that we are writing our protocols inside each node. We have the ability to write all of the interior protocols (or student protocols) between the Application and Physical Layers (and even to rewrite these two layers if we need). The protocols may be as simple or as complex as desired, and should follow a layered approach to isolate distinct responsibilities. For example:

  • a network of only 2 nodes will only need a single layer between the Application and Physical Layers (usually termed the Data-Link Layer). This protocol will simply have the responsibility of reliably moving frames across the single bidirectional link between the two nodes.
  • a network consisting of more than two nodes, will (ideally) require an additional layer between the Application and Data-Link Layers (usually termed the Network Layer) to manage packet routing, possibly congestion- and flow-control, and message fragmentation (and possibly some other responsibilities).
  • a network in which the nodes may crash or the links may be severed will (ideally) require an additional layer between the Network and Application Layers (usually termed the Session Layer) to ensure that old packets that have been ``floating'' around the network between crashes are not considered as part of the current communication sequence, and
  • a network in which we are conscious of limited bandwidth and security may require an additional layer between the Session and Application Layers (usually termed the Presentation Layer) to provide compression and/or encryption of our data before it is transmitted.

Of course, these ideas and the responsibilities of each layer are not peculiar to cnet protocols and are very well motivated and described in many undergraduate textbooks on data communications and computer networking. However, cnet supports these ideas by not getting in the way, by not imposing particular methodologies or data structures on your protocols.

Protocols are written using an event-driven programming style as if we were writing the protocols as part of an operating system's kernel. As well as handling network-related events, a traditional operating system must handle other events for its file-system, devices, and to let user-level processes execute. For this reason, our protocols must execute as quickly as possible, and then relinquish control to cnet (as if an operating system) to permit other activities. cnet is unaware of your using one or ten interior layers - cnet only provides the highest and lowest layers, and an application programming interface (API) to interact with these layers.

The lifetime of a message

It is instructive to consider the lifetime of a message in cnet. A message is first generated in the Application Layer of, say, node0 for delivery to the Application Layer of node1. The Application Layer informs our interior protocol layer(s), via an event, that a message requires delivery. Our interior protocols do not know, nor care, about the contents of this message, and simply treat it as a block of bytes. Because the nodes are simulating distinct computers, we must use the provided Physical Layer, accessible via each node's link number 1, to deliver the message. From the point of view of the message, this is what happens, assuming that all goes well:
  1. node0's Application Layer generates and announces the message,
  2. node0's interior protocol calls CNET_read_application to read (and thereafter own) the message and its intended destination (node1),
  3. node0's interior protocol does whatever it wants with the message,
  4. node0 calls CNET_write_physical to transmit a block of bytes (presumably including the message) via its link 1,

  5. after a short transmission delay, the bytes arrive at node1's Physical Layer via its link 1,
  6. node1's Physical Layer announces, via an event, the arrival,
  7. node1's interior protocol calls CNET_read_physical to read the bytes,
  8. node1's interior protocol does whatever it wants with the message,
  9. node1's interior protocol finally calls CNET_write_application to deliver the message to its Application Layer.

As stated, the above sequence assumes that nothing goes wrong - and if nothing went wrong, writing network protocols would be no fun! We must obviously call the cnet functions correctly, but more importantly our interior protocols must detect and manage errors in the network itself because cnet's Error Layer randomly corrupts and loses frames. If we wish to only develop higher-layer protocols, we can bypass cnet's Error Layer entirely by calling CNET_write_physical_reliable, or get a frame to the correct destination node in a single action by calling CNET_write_direct.

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