cnet v4.0.4  

home topology files command‑line options the core API FAQ download and install

Drawing datalink frames in cnet

cnet can present a limited visualisation of datalink frames traversing the Physical Layer of any LT_WAN link. Using just colours and lengths, it is possible to display both data and acknowledgment frames, and the contents of some of their fields. In combination, these features may be used to debug implementations of Data Link Layer protocols.

You may view a LT_WAN link's frames by clicking the right mouse button (control-click on Macintoshes) on the link. Frames simply move from left-to-right or right-to-left until they reach their destination. If the frame becomes lost, because the link's probframeloss attribute is non-zero, only the frame's silhouette (an all white frame) will reach the destination. If the frame becomes corrupted, because the link's probframecorrupt attribute is non-zero, a lightning bolt appears and only a singed (all grey) frame will reach the destination. Of course, both data and acknowledgment frames may be lost and corrupted.

Below, we see a selective-repeat protocol experiencing frame loss (the upper ghostly white data frame number 5) and frame corruption (the singed grey data frame number 3), while other data and acknowledgment frames are also being exchanged.

As with most activities in cnet, frames are drawn using an event-driven approach. If of interest, the cnet event EV_DRAWFRAME is delivered to the running protocol when cnet needs to know how to draw a frame. cnet has no knowledge of the format of the data frames it is delivering, and so the protocol writer must indicate which colours, field lengths, and strings are to be used to draw each frame. cnet defines the CnetDrawFrame datatype which provide C string constants to request colours, such as "red", "blue", .... The colours and lengths (in pixels) of up to 16 fields of each frame may be supplied.

You may also request that a short text string, up to DRAWFRAME_TEXTLEN (=16) bytes in length, be drawn (centred) on each animated frame. cnet will only deliver the EV_DRAWFRAME event to the protocol once per frame, and the protocol is not, itself, responsible for drawing or moving each frame. This enables you to concentrate on writing the protocol, not any visualisation.


To request that data frames are drawn according to your own (limited) design, register an event handler to receive the EV_DRAWFRAME event (typically in your EV_REBOOT handler):

void reboot_node(CnetEvent ev, CnetTimerID timer, CnetData data)  { ..... CHECK(CNET_set_handler( EV_DRAWFRAME, draw_frame, 0)); ..... }

Finally, define an event handler to receive the EV_DRAWFRAME event. cnet passes to the handler, in the CnetData parameter, a pointer to an instance of the CnetDrawFrame datatype. This pointer provides access to colour, pixel (length), and text arrays, as well as a pointer to the data frame to be drawn. Again, cnet does not know the format of the protocol's data frame. In the following example code, the FRAME datatype, and its kind and seq structure fields are known to the protocol, but not to cnet. (If you're unsure of what's happening here, just copy the first few lines this code, verbatim):

void draw_frame(CnetEvent ev, CnetTimerID timer, CnetData data) { CnetDrawFrame *df = (CnetDrawFrame *)data; FRAME *f = (FRAME *)df->frame; switch (f->kind) { case DL_ACK: df->nfields = 1; df->colours[0] = (f->seq == 0) ? "red" : "purple"; df->pixels[0] = 10; sprintf(df->text, "ack=%d", f->seq); break case DL_DATA: df->nfields = 2; df->colours[0] = (f->seq == 0) ? "red" : "purple"; df->pixels[0] = 10; df->colours[1] = "green"; df->pixels[1] = 30; sprintf(df->text, "data=%d", f->seq); break } }

This example code will draw each acknowledgment frame with 1 field, 10 pixels long, and each data frame with 2 fields, totalling 40 pixels long. Frames with a sequence number of 0 will will be drawn in red; other frames will be drawn in purple. Data frames will have a second field, representing their payload, drawn in green. Both types of frames also request that a short text string, displaying their sequence number, be drawn (centred) on their animated frames

RESTRICTIONS:

For best results, simulations drawing drames should run slowly. Because the protocol writer has control over the length (size) of the frames drawn, it is possible for frames moving in the same direction to be drawn on top of one another (although they will not overtake one another!). Clearly this doesn't represent reality too well. The following conditions provide a reasonable representation:

messagerate = 1000ms wan-propagationdelay = 1500ms

cnet v4.0.4 - [email protected]