There were 3 programs in CSC 464, which I've encapsulated in this one project entry. Below is a description of each program.

Program 1: trace

trace is a program that takes in a packet trace file (pcap) captured from Wireshark and outputs information about each packet in the file. Basically, it takes each header in the packet in byte format, then outputs it in a human readable format, and moves onto the next header.

It handles the following header types:

• Ethernet
• ARP
• IP
• TCP
• UDP (just the port numbers)
• ICMP

It properly handles the TCP pseudo header, and also validates checksums.

Program 2: chat

chat is a client and server chat program, where clients can connect to a server and message other clients. It uses TCP for transporting packets, and handles four types of client requests:

• Unicast messages
• Broadcast messages
• Multicast messages
• A request to see all other clients connected to the server

Each client connects with a "handle", which is just a chosen name. The server then maintains a handle table to keep track of all the clients it is connected to and their respective sockets. The server also maintains a poll set to handle multiple connections as well as multiple types of connections (initial connection vs communication).

This assignment was really hard, but I learned a lot about how TCP connection works. I also think the code I wrote is really solid, using a lot of functional programming. Professor Smith kept telling us to break up our code into individual functions that do one thing, and then test those functions and make sure they work. As a result, I ran into very few bugs throughout the assignment, and was able to structure my code in a fairly logical and easy to work with way.

Program 3: rcopy (aka everything goes badly)

rcopy is a client and server file transfer program. Unlike program 2, it uses UDP and the selective reject protocol for sending packets. The client requests a file from the server, and also provides a window size and a buffer size.

• server: Given the window size, the server maintains a "window", which is basically the number of packets it will send before it needs an acknowledgement for those packets from the client. It also buffers all of the packets it sends, until it gets an acknowledgement. Once it gets an acknowledgement, it will slide the window forward, and send another packet.

• client: For received packets that are in order, the client will send an acknowledgement for all of the packets it has received in order up to this point and write that packet to a new file. If it receives an out of order packet, it buffers it and requests the next packet it was expecting to get. If it receives a corrupted packet (it runs a checksum to determine this), it drops the packet.

The main difficulty is that any packet, including acknowledgements can be lost or corrupted, and we used special function for sending packets provided by Professor Smith to simulate packets being lost and corrupted with some specified probability. This meant that our client and server needed to handle a bunch of different cases.

This complexity led to one billion bugs that I spent a long time fixing, and it also resulted in the image I chose for this project entry. I did learn a lot though.

The image for this project entry is from a message I sent to my roommates while working on this program.