ICS 451 (Data Networks) Project 3

The goals of this project are:

1. to implement a reliable transmission protocol
2. to implement a multicast routing protocol

This is a group project. You may do it individually or in groups of up to 4 people. Your implementation must interoperate with the implementations of at least 2 other groups.

You may choose your programming language, you do not have to use C. If you are selecting an unusual language, please check with the TA first to make sure he will be able to grade your project. C, C++, and Java are all acceptable; for other languages the TA has final say on whether a language is acceptable.

The project is due Monday, December 7th 1998, at 5pm HST. Submission is electronic (see below). Late submissions lose 10% of the grade for each day they are late for the first 5 days after the due date, and will be granted no credit whatsoever after 5pm on December 12th.

The assignment is to write a multicast router which transfers data reliably on top of UDP. Multicast occurs by groups. Hosts and routers can join specific groups or detach from specific groups. Each host and router is identified by an IP number and a UDP port number. Groups are identified by a single byte. The protocol for data exchange does not specify which host or router originated each message, though individual messages (for example those on group 0, see below) may carry this information.

Project Specification

1. a data message is identified by an initial byte of 0, followed by a byte indicating the destination group, 2 bytes indicating the sequence number, 4 bytes indicating the IP number of the immediate sender of this packet (which must be a connected host or router), 2 bytes for the port number of the immediate sender of this packet, 2 bytes of padding, and up to 500 bytes of data. Sequence numbers count packets, and start counting at 0 when a router/client receives the group join message.
2. an ack message is identified by an initial byte of 1, followed by a byte indicating the group for which this is an ack, 2 bytes indicating the ack number, and the IP and port number of the sender of the ack. An ack for a data message with sequence number x carries ack number x (unlike some of the protocols discussed in class, especially TCP).
3. a group join message is identified by an initial byte of 2, followed by one byte indicating the group number, 2 bytes indicating the port number of a sender for this group, 4 bytes indicating the IP number of a sender of this group, 4 bytes indicating the IP number of the sender of this message, and 2 bytes indicating the port number of the sender of this message.
4. a group detach message is identified by an initial byte of 3, followed by one byte indicating the group number, 2 bytes indicating the port number of the sender of this message, and 4 bytes indicating the IP number of the sender of this message.
5. a link state message is identified by an initial byte of 4, followed by one byte with a value of 0, indicating the sender is a router, or a value of 1, indicating the sender is a host, 2 bytes indicating the port number of the sender of this message, and 4 bytes indicating the IP number of the sender of this message.

Group zero (a group identified by a byte with a value 0) is reserved for routing, and every router joins the group as soon as they come up. Data messages for group 0 have as contents a router ID (4 bytes of IP number and 2 bytes of UDP port), followed by a 2-byte count of how many links are listed in the message, followed by that many links. Each link has an ID (6 bytes), followed by 1 byte indicating whether this is a host (1) or a router (0), followed by an unused byte. The C declaration for group zero data packets is:

struct entry {
  int IP;
  short port;
  char is_host;
  char pad;
}
struct g0 {
  int sender_IP;
  short sender_port;
  short count;
  struct entry links [count];
}

Client

Any command line arguments beyond the first three must be in groups of 4, and have the form: group number, IP number, port number, number of packets. They identify groups that the client must attempt to join whenever the connection comes up. If the connection goes down all groups are assumed detached; otherwise, the client must detach from the group after the specified number of packets has been received. The client must print to the display the group number and sequence number of all data packets received.

A client may get a group join message. If so, the client will send a data packet to the group once every 10 seconds. The packet contains 8 bytes: 4 bytes of (sender) IP number, 2 bytes of (sender) port number, and 2 bytes of sequence number, starting with 0. Transmission must cease when the client gets a corresponding group detach message (group detach message for groups the client is not sending to should be ignored).

Whenever a data packet is received, the client must send a corresponding ack packet if the sequence number is less than or equal to the sequence number expected. Whenever a data packet is sent, the client must start a timer that will retransmit the packet if there is no corresponding ack within approximately 10 seconds (you may use the link-state timer to retransmit messages).

Router

The router also maintains a connection to group zero whenever possible by:

1. when the links to all of the directly attached routers are down, no connection to group zero is possible.
2. when the link to at least one of the directly attached routers is up, a request for connection to group zero is sent to that router, with that router's address as the sender (source) for multicast group zero.
3. each router should be attached to group zero through at most one other router, or routing loops and multicast storms may take place. A router may detach from its upstream router and attach to the same group through a different router.

When a router receives a link state table as a data message on group zero, it must:

• update its internal map of the network
• update its internal routing table (the routing table may be constructed on the fly from the network map, and need not be kept explicitly. In that case no update is needed at this step)

When a router notices a change in state on one of its links (up or down), it must update its internal link table and send the updated link table as a data message on group zero. Each router must also send its current link table to group zero every 10 seconds.

When a router gets a group join message, the following possibilities exist:

• the message is not from a directly attached host. The router ignores the message.
• the router already carries the group. In this case the router adds the new destination to its internal forwarding tables and starts forwarding to the new host or router.
• the router does not carry the group. In this case the router adds the new group and destination to its internal forwarding tables and forwards the group join packet, with its own IP number and port number as the packet sender's ID, to the next router in the direction of the specified source. The next router must be identified by the internal routing tables. If the specified source is not in the routing table, the router drops the group join packet.

When a router gets a group detach message, it detaches the sender of the message (if the sender is in the multicast forwarding tables, otherwise the message is discarded). If this was the last host to which this group was being forwarded, the router must also detach from its upstream provider.

Finally, when a router gets a data message, it must check the sequence number, acknowledge the packet if it is the expected sequence number or less, discard the packet if it is not the expected sequence number, and forward it otherwise. Forwarding means sending the packet to each of the downstream hosts and routers, and retransmitting if no ack has been received after 10 seconds (or when the link state timer fires). Packets must be buffered until either acked by each of the downstream hosts or until the absence of link state messages declares as "down" the link that each missing ack should be received on.

Project Deliverables

1. The group name and a list of members of the group, including names, e-mails, and IDs. This should be turned in as hardcopy, no later than class time on Monnday December 7th, 1998.
2. A list of the other groups (if any) with which your project has interoperated. Interoperation means successful communication with a client and a router by your client and your router. This should be sent to the TA by email (each group should send 1 email with the names of at least two groups you successfully interoperated with). If no mail is received, it will be assumed that you did not successfully interoperate with other groups.
3. All your code (sources and makefiles only). The source code must compile and run on uhunix2. Submit your project by running ~sunx/public_html/ics/ics451/Project_3/client on uhunix2.

Suggestions

1. Timing
   This is a challenging project, and I am not planning on giving any extensions. Start early. Pick a team within 2 days, and work with your team to plan the project.
2. Design and Management
   You will need to do a lot of management for this project. You must do a high-level design, i.e. decide what functions are implemented by what modules, and approximately how. Then you must determine how to distribute responsibilities in ways that are both fair and take advantage of different group member's strengths. You will have to choose a programming language, review each other's code for bugs, negotiate with other teams for testing times, pick a team name, and more. Start early and plan ahead.
3. Testing
   You should be able to build an entire multicast network by running multiple copies of your router and client at the same time (make sure they have automatic mechanisms for picking UDP port numbers).
4. Threads
   Some of the algorithms are time-dependent. It is the intent of this project that a single timer thread that wakes up every 10 seconds should be sufficient to implement the protocol. This requires that state be stored in a way that lets the timer thread figure out what to do. You are also welcome to use multiple threads. Either way, it is probably a good idea to print a message whenever a thread wakes up or is about to go to sleep. You will need a receiver thread, which (depending on your design) may or may not be the same as the main thread. Also, if you do not wish to use pthreads, you may use the Unix signal handling mechanism to implement the timer thread (see "man alarm").
5. Grading
   Either one of the router or client alone can get you up to 60% of the grade. If you are not sure you will be able to finish the project, it may be a good idea to build one first, then start on the other. It should be easy to test routers against themselves (without clients), and a client should test at least minimal functionality when connected to another client, and of course full functionality when connected to another team's router. Note that a lot of the code for clients and routers (timer threads, packet decoding) may be the same.
6. Reliability
   The algorithm for reliable transmission is a lot like the Alternating-Bit protocol, but the sequence number space is 16 bits.
7. Protocol bugs
   I do make mistakes. If you find mistakes in the design of this protocol, please send mail to me or to the mailing list. I will probably reply within 24 hours (except on weekends). If you are not subscribed to the mailing list, please send a message now with "subscribe ics451-l firstname lastname" in the body, to listproc@hawaii.edu.