Continue using the same settings used for the previous project (port numbers)

You are required to implement the CBT algorithm on top of project one.

• The project should be implemented in C. Other languages will not be accepted, that includes C++, Java, Perl, Python, VBasic, Fortran, assembler, etc.
• You'll use UDP sockets.
• You must submit a .tar.gz or tar.bz2 with all the files. This includes a Makefile and a README
• Your code must compile on Sundance (SunOS 5.6)

You should build upon project one. In other words, CBT will rely on the routing protocol you implemented to build the shared tree. Your program will read similar parameters as the previous project, with the adition of multicast information.

This project will simulate a network with multicast traffic using the CBT algorithm. We will have only one core and only one multicast group, which should make things simple. Nodes will be able to join / leave the group. The CBT tree will adapt to topology changes.

You should follow the algorithm described in the CBT paper with some considerations.

• There will be only one core
• You do not need to handle core failures
• All routers (nodes) are considered CBT enabled
• State in the routers will be set by the JOIN request (instead of the JOIN-ACK)
• You don't need to implement the tree loop detection

Nodes will receive topology configuration and node configuration in the same manner as the previous project, via topology.config and node.config (which can be command line parameters or build in filenames). The nodes should also be configured with the following comand line parameters: the core of the CBT ( -c # ), an optional receiver flag ( - receiver ), if present the node will be a multicast receiver, and an optional sender flag ( -sender ), if present the node will send data to the multicast group.

Nodes can be brought up and down (by starting/killing corresponding processes) and the CBT tree should update acordingly. If a node notices its child link is dead it will remove it from the tree. A node can be killed and started with new sender and/or receiver flags. The core will not be killed. Upon a non-core CBT router failure, its direct children need to rejoing the tree by sending the JOIN again, a flush tree message is not necesary

If a node is a sender, it will send periodic packets (every 10 seconds) to the group with it's node ID and a sequence number as the payload. This will emulate data transmission. Other nodes that see/forward these packets should print the contents of the packet and a timestamp.

Nodes wishing to join the tree will send a JOIN packet periodically until the receive multicast data. We'll consider this as piggy-backing the JOIN-ACK instead of the explicit JOIN-ACK

Nodes should print CBT information upon a CBT change. That includes a timestamp, node ID, parent node ID and child node ID(s).

Your code should be portable between architectures. It should account for at least machine endianess.

Discuss with your friends/classmates, but don't share code. If you have any questions about sharing ask first. Don't get yourself into trouble.

Test your software with different scenarios. Kill nodes and see how the topology updates. You might want to try it yourself on paper and compare the results with your program.

Don't wait till the last minute to start working on your project! Even if you know all the theory and you are good at programming with sockets in C, it's always better to finish early than to be pressed in the last 24 hours.

node.config You can expect a maximum of 15 nodes, though the examples will probably use from 8 - 12. The format of the file is:

node# port IP

topology.config The format of the file is

node#	node#	distance

For example, use 1 as your core, 2 as a sender. 3,4,7,8 as receivers.

The source code should documented. Also, you should include a README file describing the program and how to use it. If your program has bugs or is not finished, this document should describe the reasons and you might get credit for the work done.

Programs will be tested with a new configuration topology similar to the example ones.

• Compile
• Run
• Correct CBT calculation (joins)
• Correct CBT calculation (leaves)
• Correct update of the CBT upon CBT non-core router failure
• Nodes should detect if the core is not reachable
• Portable code (see above description on portability)
• Use the IP field in the node.config so that your program can run on different machines

The following features are not mandatory and should be implemented only as an enhancement to your program. If you complete them you will get extra points, however, you won't get more than 100 points for the project. The are not in order.

• Stamp packets on every node. Receiver node will print all the stamps so that the path traveled by the packet can be seen.
• Use a flush tree packet to handle non-core CBT router failures
• Allow nodes to be killed, and then restarted with a new topology.config (with the weights changed) and the other nodes (even neighbors) will then update the link weight. This is tricky.
• Update the CBT tree if a better route becomes available. This is done by monitoring the unicast routing tables.

You need to email the source (tar.gz) to the TA before the due date, May 10. Please use 252-Project2 Submission as your subject.

You can resubmit at any point prior to the due date