1.0 Overview

 You will write a ``node'' program that is run on up to 10 different machines (though extending beyond 10 should be trivial). Each ``node'' program will read from a topology file and establish a virtual topology of unicast links. The links will actually be implemented using TCP connections. Each link will have a virtual cost. Using Node 1 as the one and only source you will need to build a logical representation of a multicast tree. When Node 1 begins sending packets, each packet should be delivered across the multicast tree, but only to nodes that are group members.

 Two input files will be needed: the topology file mentioned above, and an event file. The event file will contain a list of times and corresponding node actions. These events will be join/leave messages from nodes wishing to join/leave the multicast group. The node which initiates the event must send an event message to the next-hop, upstream router who must properly act on the message, either adding the node to the multicast tree and passing the message further upstream or pruning the link from the multicast tree.

 The output from your programs will be two files for each node. The first will contain a history of events for each node and the second will contain a transmission summary. The possible events are for data packets only and include: transmitted (source node only), forwarded (intermediate nodes only), discarded, and received.

 The transmission summary will include information about the total number of packets sent, received, forwarded, and dropped by each node. 

2.0 Input Given

• Topology File (click here for an example)
• You should be able to read the topology configuration file and create a logical representation of the unicast routing topology in your simulator. The following format will be used:

 

 
 
 

<number of nodes in tree> <duration> <interval> <dense/sparse>

<node #> <IP address of host> <starting port number>

<node 1> <node 2> <hop cost>

• The dense/sparse option specifies what type of routing protocol will be run for this particular configuration.
• <duration> above is the duration of the simulation
• <interval> above is the resolution of time unit used in the simulation ( in seconds ).

 

 
 
 

• Event File (click here for an example)
• The following format will be used:

<time> <node #> <event type>

• <event type> is either join or leave.

 

 
 
 

• The time component will always be an integer greater than zero. The time component is actually a ``sequence number trigger time''. In addition to data packets, the source also broadcast heartbeat packets, one every <interval>.  Heartbeat packets are sent to all receivers and are independent of data packets sent to the multicast address. Heartbeat packets are necessary in order to provide a coarse-grain global clock to synchronize events. Note that the heartbeat messages will be sent by source and all the nodes in the topology will receive it. This transmission will be using a truncated broadcast tree based. That is, after you create the topology, you need to create a tree covering all the nodes in the topology. This tree is then used to transmit heartbeat messages.

3.0 Output Format

• log-<node #>.out: (click here for an example)
• The log-<node #>.out file should contain a sorted list of events (you'll have to sort based on the entire line because only the entire line will be unique) using the following format:

<time> <action node> <secondary node> <action>

• The <action> is either join, leave, prune, snd, fwd, rcv, rpf, or drp.

 

 
 
 

• Most actions involve two nodes: the action node and the secondary node. The action node is the node in which the event takes place, and the secondary node (coupled with the action node) is used to identify the link over which the packet will flow (in the case of a send), was sent (in the case of a receive), or won't be delivered (in the case of a rpf, ttl, or prn).

 

 
 
 

• There are three reasons why a packet may not be forwarded: (1) rpf, reverse path first check which failed, or (2) prn, dropped because of prune state.

 

 
 
 

• Sometimes there will only be single nodes (in the case of a join or leave). In this case the secondary node should be made the same as the action node.

 

 
 
 

• summary-<node #>.out: (click here for an example)
• The summary-<node #>.out file should contain one line per node, sorted by node number with the following information:

<node #> <pkts snd> <pkts fwd> <pkts rcv> <pkts rpf> <pkts drp>

4.0 Detailed Operation

• For this assignment, there is a strict requirement that you turn in exactly two files: node.c and a Makefile.

 

 
 
 

• The command line parameters for the executable should be:

node <node number> <topology file> <event file>

• The two output files created should be log-<node #>.out and summary-<node #>.out.
 
 
• The source will always be Node 1. However, because there is only one node.c program, the send function will be included in each node. Your node.c should determine whether it is Node 1 and then initiate the heartbeat and data packet transmission if it is. Data packets should be sent once every two intervals, and heartbeat packets should be sent once every interval. Finally, ONLY data packets and not heartbeat packets are counted in the log and summary output files.

 

 

• Upon startup, each node will need to form a unicast routing table using a link state style protocol (since all nodes will have access to the topology and link costs). You will also need to create a truncated  broadcast tree for the heartbeat packets.

 
• Upon startup, a TCP connection should be opened for each link specified in the topology file. The link should be opened by the node with the lowest number. For this reason, when running a program, always start nodes from highest to lowest (so that when the lower numbered node in a link is started, the peer will already exist).

 

 
 
 

• Handling port assignments will be a little bit tricky, but use the following convention: The lower numbered node will connect to the higher numbered nodes IP address. The port number used will be the number specified in the topology file plus the node number of the client node. For example, if 5 is connecting to 6 and 6 has a port number of 38000 in the configuration file, node 5 should connect to port 38005.

 

 
 
 

• You will have to implement a dense-style broadcast-and-prune version and a sparse-style join-and-graft style of protocol.
• You will need to create state in each node based on whether traffic should be forwarded or dropped based on prune state. Since there is only one multicast group there will only be one entry for each outgoing link.

 

 
 
 

• A node should not actually print out any messages while executing. This is so the nodes can be run in the background, possibly on the same machine.

 

 
 
 

• You will need to create both control packets (for joins, leaves, and heartbeat packets) and data packets. This will require you to create a protocol on top of TCP so that nodes know whether an incoming packet should be forwarded/dropped or processed. You are free to implement these headers however you like.

 

 
 
 

5.0 Turnin

• Electronic turnin: Use the turnin command to turnin node.c and Makefile files only.

       $>    turnin hw3@cs276  files-and-directories
 
 
• Hardcopy turnin: Turnin a copy of the source code as well as a brief (1 page max) summary of the differences between sparse and dense mode protocols. You should identify ways of quantitatively comparing the performance of the two (packet hops for example) and state whether there are cases when dense is better than sparse and vice versa. Don't forget to
• Turnin joint code
• Turnin separate write-ups

 
 

6.0 Grading

• 40: dense-mode protocol works correctly
• 40: sparse-mode protocol works correctly
• 20: analysis (write-up)