The cnet simulation modelcnet 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, linkinfo, 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.
The lifetime of a messageIt 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:
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 (firstname.lastname@example.org)|