The cnet network simulator - node types, event types, and error types
Keywords: network simulator simulation protocol undergraduate teaching

### cnet's node types, event types, and error types

cnet's provides three enumerated data types, each defined in its `<cnet.h>` header file.

### The `CnetNodeType` type

Each node is either a host (a workstation) or a router. The type of a node may be determined by examining its value of `nodeinfo.nodetype`. For example: `

        if(nodeinfo.nodetype == NT_HOST)
            (void)CNET_set_handler(EV_APPLICATIONREADY, appl_ready, 0);

`

CnetNodeType | meaning
--- | ---
NT_HOST | this node is a host with an Application Layer and keyboard
NT_ROUTER | this node is a router without an Application Layer or keyboard

Note that calls to the functions

`CNET_write_application, CNET_read_application, CNET_enable_application, CNET_disable_application and CNET_set_handler(EV_APPLICATIONLAYER,...) or CNET_set_handler(EV_KEYBOARDREADY,...)`

are only valid if called from a node of node type `NT_HOST`.

### The `CnetEvent` type

Events occur in cnet when a node reboots, the Application Layer has a message for delivery, the Physical Layer receives a frame on a link, the keyboard provides a line of input, a link changes state (either up or down), a timer event expires, a debugging button (under X-windows) is selected, and a node is (politely) shutdown (no event is delivered if a node pauses, crashes or suffers a hardware failure). All such events are of type `CnetEvent`. Interest may be registered in each event with `CNET_set_handler`; events are received as the first parameter of each event handler, and their invocation may be traced with `CNET_set_trace`.

CnetEvent | meaning
--- | ---
EV_NULL | this event is used internally and is never seen by your protocols
EV_REBOOT | raised as reboot_node(EV_REBOOT, ... , ...)
EV_SHUTDOWN | raised before cnet is (cleanly) terminated
EV_APPLICATIONREADY | raised when there is a message ready for delivery
EV_PHYSICALREADY | raised when a frame arrives at one of the links
EV_KEYBOARDREADY | raised when an input line is entered from the keyboard
EV_LINKSTATE | raised when a link changes state (either up or down)
EV_DEBUG1..EV_DEBUG5 | raised when one of the debug buttons (under X-windows) is pressed
EV_TIMER1..EV_TIMER10 | raised when a timer on any of the 10 timer queues expires

### The `CnetError` type

Most cnet library functions return the integer `0` on success and the integer `-1` on failure. The most recent error status is reflected in the global variable `cnet_errno`. All values of `cnet_errno` will be instances of the enumerated type `CnetError`. Errors may be reported to `stderr` with `cnet_perror()` and their error message string accessed by indexing `*cnet_errstr[]` with `(int)cnet_errno`. For example: `

        if(CNET_write_application(msgbuffer, &msglength) != 0) {
            /* an error has occured */
            if(cnet_errno == ER_BADSESSION) {
                /* handle this special case */
                ....
            }
            else {
                cnet_perror("writing to application");
            }
        }

`

CnetError | meaning
--- | ---
ER_OK | No error
ER_BADARG | Invalid argument passed to a function
ER_BADEVENT | Invalid event passed to a function
ER_BADLINK | Invalid link number passed to a function
ER_BADNODE | Invalid node passed to a function
ER_BADSENDER | Application Layer given message from an unknown node
ER_BADSESSION | Application Layer given message from incorrect session
ER_BADSIZE | Indicated length is of incorrect size
ER_BADTIMER | Invalid CnetTimer passed to a function
ER_CORRUPTDATA | Attempt to transfer corrupt data (only seen if -e provided)
ER_LINKDOWN | Attempt to transmit on a link which is down
ER_NOTFORME | Application Layer given a message for another node
ER_NOTREADY | Function called when service not available
ER_NOTSUPPORTED | Invalid operation for this node type
ER_OUTOFSEQ | Application Layer given message out of sequence
ER_TOOBUSY | link is too busy/congested to handle request

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