The cnet simulation model

cnet supports a model of networking in which nodes are either hosts, routers, mobiles, or accessspoints. The different types of nodes have different properties. For example, host and mobile nodes have an Application Layer that generates messages for delivery to the Application Layers of other hosts or mobiles. While hosts and mobiles never generate messages for themselves, routers and accesspoints cannot generate messages at all.

The nodes are connected by a variety of network links, using wide-area-networking (WAN), local-area-networking (LAN), or wireless-local-area-networking (WLAN) links. Introductory protocols will typically employ only hosts and WAN links.

The cnet simulation model appears in the following diagram:

cnet itself provides all nodes with a Physical Layer and each host and mobile with an Application Layer. In addition, a hidden Error Layer lurks above each Physical Layer, and randomly introduces frame loss or corruption 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 rest 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.

Nodes occupy positions on a large simulation 'map'; hosts, routers, and accesspoints are stationary, but mobile nodes may move around the map under their own programmatic control. A few obvious restrictions apply to the possible combination of nodes and their links - while hosts, routers, and accesspoints may have any number and type of network links (including wireless WLAN links), mobile nodes may only have a single WLAN link.

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 node. 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[0], linkinfo[1], linkinfo[2], and so on. Other than for the LOOPBACK link, there is no restriction on which link types may occupy which physical positions.

Protocol layers

cnet protocols are written from the point of view of each node. We imagine that we are writing our protocols inside the operating system's kernel of each node. We have the ability to write all of the interior protocols between the Application and Physical Layers. 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 a Data-Link Layer protocol). This protocol will simply have the responsibility of reliably moving frames across the single error-prone 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 a Network Layer protocol) 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 a Session Layer protocol) to ensure that old packets that have been "floating" around the network between crashes are not considered as part of the current communication session, 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 a Presentation Layer protocol) 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 the cnet simulator, 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, and 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) for it to schedule 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, and assuming that all goes well, this is what happens:

1. node0's Application Layer generates the new message and announces it with the EV_APPLICATIONREADY event,
2. node0's interior protocol calls CNET_read_application to read (and thereafter own) the message, and to learn its length and intended destination (node1),
3. node0's interior protocol does whatever it wants with the message, typically including it in the payload of a frame or packet structure for transmission,
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, dependent on the number of bytes being transmitted, the bandwidth and propagation delay of the communication medium, the bytes arrive at node1's Physical Layer via its link 1,
6. node1's Physical Layer announces the arrival, via the EV_PHYSICALREADY event,
7. node1's interior protocol calls CNET_read_physical to read (and now own) the bytes,
8. node1's interior protocol does whatever it wants with the message, typically copying it from the payload of any structure used to transmit 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 functions in cnet's API 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.