Reference no: EM131858069

Objectives

The programming assignment is intended to give more experience with the cnet network simulator API and its use in developing a simple protocol.

Part 1: The CNET API

This part requires that you familiarize yourself with the contents of the following files:

File/Directory	Remarks
cnet.h   cnet's FAQs ticktock   stopandwait	the cnet standard header file (make a local copy of the file from directory $CNETPATH; you may need to refer to it in the future) linked to from the main documentation page (in the examples directory) the protocol illustrates the use of timer events (in the examples directory) the protocol implements a stop-and-wait protocol to achieve reliable communication between two nodes

Answer the following questions.

1. Use the data types defined in cnet.h to complete the following C-struct. If no suitable definition is found in cnet.h use standard C data types.

typedef struct {

....   node_t;        // node type, e.g., NT_ROUTER

....   mytimer;       // a timer identifier

....   src, dest;     // user defined node addresses (not node numbers)

....   ap_pos;        // the (x,y,z)-coordinates of an access point

....   code;          // stores the return value of function CNET_ccitt()

} PACKET;

2. In cnet, each node independently executes a copy of the protocol specified in a topology file. Information about a node is stored in struct nodeinfo. How can a node access its current simulation time (the time advanced by the occurrence of events since the node's last EV REBOOT)? How to print such a value using a printf statement? (Hint: check the FAQs as well as cnet.h.)

Remarks: The simulation time is typically different from the wall-clock time. For example, if the run-speed parameter in the GUI is set to a value other than normal, the simulation time may run either faster or slower than the wall-clock time. Also, one should not assume that the simulation time is synchronized between all nodes by default. Some nodes may have pending undelivered events, and thus their simulation time may be lagging others. The design of the simulator, however, ensures that each node encounters a valid sequence of timed events.

3. Download protocol file ping-W18.c and topology file PING-W18 linked to the course's WEB page. Familiarize yourself with the working of the protocol. Run cnet on the topology file. In the GUI, click on any node to open its output window. Press the DEBUG0 button, labelled Node Info, to obtain more output. Record one of the displayed values of variable delta.

(a) Explain the recorded value of delta given the default settings of the various parame- ters in the topology file.
Note: you may use "cnet -p topologyFile" to obtain the default settings of a topology file.
(b) Explain how to modify the topology file to make delta approximately equal to 1.5 second.

4. In the stopandwait.c protocol, can FRAME SIZE(f) be different from sizeof(f)? Explain.

5. The contents of array msg 1 below is an original transmitted message. The contents of array msg 2 is a corrupted received message obtained by performing a circular right shift operation.

unsigned short msg_1[]= {10,20,30,40,50,60}, msg_2[]= {60,10,20,30,40,50};

Use function CNET IP checksum to compute the checksum for each message. Write the obtained values in your submitted answer to this part.

Note: If the two checksum values are equal then this error detection code fails to detect this type of message corruption.

6. What does the CHECK macro do when the enclosed function call returns an error value (typ- ically 1)? Explain how the information mentioned under API FOR ERROR HANDLING in cnet.h can be used to report an API error to the user (using some easy to understand text message) while allowing the simulator to continue execution.

Remark: You may test the effect of the macro by checking, for example, its behaviour when
CNET write physical is called with a non-existing link.

7. Does the stopandwait.c protocol detect corrupted frames? If yes, explain how this feature is programmed (when appropriate, give C code fragments to illustrate the steps in- volved).

Part 2: Obtaining Topology Information

In this part, you are asked to develop a simple protocol that allows a node to learn about its neigh- bours. In the real world, for example, when a router is rebooted it starts in a state where it does not know any of its neighbours. The developed protocol enables routers to acquire such important information. CNET mimics this behaviour; after the initial node reboot, a node does not know any information about any of its neighbours. It knows, however, that it has nodeinfo.nlinks incident links numbered sequentially starting from link number 1. (Recall that link number 0 is a loopback link that may be used for debugging.)

Your task in this part is to develop a topology learning protocol that enables a node to build a table where the ith entry, 1 i nodeinf o.nlinks, stores the name, address, and type (e.g., a mobile host or router) of the node reachable by the node's ith incident link. This is achieved by sending a HELLO message to each neighbour, and receiving a corresponding HELLO ACK message that carries the neighbour's name, address, and type. More details about the required protocol is given below.

- For convenience of developing your solution, you may start with the program ping-W18.c posted on the course's WEB page. Call your program lab1.c.
- Each node in your program should send multiple HELLO messages on each incident link.
This feature may be useful if the link corrupts some of these messages.
Don't use CNET write physical reliable().
- You may assume that any node in any input topology file has at most MAX DEGREE= 32 neighbours, and each node name has at most MAX NODENAME LEN (see cnet.h) charac- ters (including the terminating null character). A node can be assigned any arbitrary valid integer address.
- Program ping-W18.c prints some information when the DEBUG0 button in a node's GUI is pressed. You are required to add to this list of printed information, the following:
1. The node type (e.g., a router)
2. The number of received HELLO messages, and the number of transmitted HELLO ACK
messages
3. A table that lists for each link i incident to the node, the number i, and the name and the address of the neighbour reachable by this link. For example, (link 2 = routerEast,
100) may be printed to indicate that link number 2 incident to the current node leads to a neighbour called routerEast whose assigned address is 100.
Use a format of your choice to print the above information.
- Test your program with file LAB1 T1 posted on the WEB site, as well as other WAN topol- ogy files of your choice.
- In your report, comment also on the following aspects:
1. Whether a node can identify its neighbours when the probframecorrupt for the links is not zero.
2. Whether the developed protocol produces logical or runtime errors when run on files
LAB1 T2 (a LAN) and LAB1 T3 (a WLAN).

Explain your findings.
- Note: It is not a good idea to place the logic of sending all of the required HELLO messages in the reboot node function. CNET initializes nodes sequentially by executing the logic in the node's reboot node function. An error occurs if a node attempts to send a HELLO message to an uninitialized node.

Deliverables

Typeset a solution file ‘answers' (text, HTML, or PDF) containing your answers to the questions in Part 1, and a program report (one or two pages) for the program in Part 2. The program report should contain the following (minimal set of) sections:

- Design Overview: highlight in point-form the important features of your design
- Program Status: describe the status of your program; mention difficulties encountered in the implementation
- Testing and Results: Explain how you tested your implementation. Describe possible API errors that you may have encountered in testing the program.
- Acknowledgments: acknowledge sources of assistance

Attachment:- Files.rar