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. Links are numbered within each node from 0 to the number of physical links that the node has, with 0 representing the LOOPBACK link. 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 the C 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.
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:
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.
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@cs.uwa.edu.au) | ![]() |