Project 1

Project Overview.
This project will introduce you to using the sockets API in the C or Java language. You will create a client application that will communicate with a server using a specific protocol. Your client's task is to follow the protocol as closely as possible and to extract a secret from the server for each stage of the protocol. The server's task is to validate that the client is following the protocol -- any deviation of the client from the protocol will cause the server to close the connection. The client and the server will communicate over UDP as well as TCP sockets. What follows is a thorough description of the protocol, broken up into stages (a,b,c,d). Remember, you must follow this protocol exactly. If you find any problems with this protocol description, or have further questions, do not hesitate to contact the TAs or the instructors.

Protocol.

The server will run on the host bicycle.cs.washington.edu, listening for incoming packets on UDP port 12235. The server expects to receive and will only send:
  • payload that has a heaader (see below)
  • data in network-byte order (big-endian order)
  • 4-byte integers that are unsigned (uint32_t), or 2-byte integers that are unsigned (uint16_t)
  • characters that are 1-byte long
  • strings that are a sequence of characters ending with the character '\0'
  • packets that are aligned on a 4-byte boundary (that is, a packets must be padded until its length is divisible by 4)
The server will close any open sockets to the client and/or fail to respond to the client if:
  • unexpected number of buffers have been received
  • unexpected payload, or length of packet or length of packet payload has been received
  • the server does not receive any packets from the client for 3 seconds
Every payload (TCP and UDP) sent to the server and sent by the server must have a packet header. This header must be located in the leading bytes of the transmission, prefixed to the payload. The header has a constant length of 12-bytes. The first four bytes of the header contain the payload length of the packet (excluding any padding to byte-align the packet). The next four bytes contain the secret of the previous stage of the protocol, psecret. The next two bytes contain an integer step number of the current protocol stage. For example, for step c2, the header's first four bytes will contain the length of the packet, the next four bytes will contain secretB, and the following two bytes will be set to the value 2. For stage a, psecret is defined as 0. The last two bytes of the header are should be set to an integer representation of the last 3 digits of your student number. This 12-byte header does count towards the length of the packet (which is to be 4-byte aligned). Throughout this project description we will use diagrams such as the following to describe packet formats; here is the format of the packet header for this project: 
		
 0               1               2               3  
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           payload_len                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             psecret                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             step               |  last 3 digits of student #  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The numbers at the top indicate the bit number in rows of 32 bits, and fields are separated by +- and | marks. The header is omitted from the following packet diagrams to eliminate redundancy, but remember that every packet has to have the header above.

STAGE a:
Step a1. The client sends a single UDP packet containing the string "hello world" without the quotation marks to bicycle.cs.washington.edu (referred to as the 'server') on port 12235: 
		
 0               1               2               3  
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                        hello world                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Step a2. The server responds with a UDP packet containing four integers: num, len, udp_port, secretA: 
		
 0               1               2               3  
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         num                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         len                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       udp_port                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        secretA                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

STAGE b:
Step b1. The client reliably transmits num UDP packets to the server on port udp_port. Each of these 'data' packets has length len+4 (remember that each packet's entire payload must be byte-aligned to a 4-byte boundary). The first 4-bytes of each data packet payload must be integer identifying the packet. The first packet should have this identifier set to 0, while the last packet should have its counter set to num-1. The rest of the payload bytes in the packet (len of them) must be 0s. The packet header length does not count towards len: 
		
 0               1               2               3  
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         packet_id                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                   payload of length len                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For each received data packet, the server will acknowledge (ack) that packet by replying with an 'ack' packet that contains as the payload the identifier of the acknowledged packet: 
		
 0               1               2               3  
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   acked_packet_id                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
To complete this step, the client must receive ack packets from the server for all num packets that it generates. To do so, the client resends those packets that the server does not acknowledge. The client should use a retransmission interval of at least .5 seconds.

Step b2. Once the server receives all num packets, it sends a UDP packet containing two integers: a TCP port number, secretB. 
		
 0               1               2               3  
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          tcp_port                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          secretB                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

STAGE c:
Step c1. The client opens a TCP connection to the server on port tcp_port received from the server in step b2.

Step c2. The server sends three integers: num2, len2, secretC, and a character: c. 
		
 0               1               2               3  
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           num2                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           len2                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          secretC                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       c       |
+-+-+-+-+-+-+-+-+

STAGE d:
Step d1. The clients sends num2 payloads, each payload of length len2, and each payload containing all bytes set to the character c. 
		
 0               1               2               3  
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|           payload of length len2 filled with char c           |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Step d2. The server responds with one integer payload: secretD: 
		
 0               1               2               3  
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         secretD                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Due Date.

The project is due on Friday, November 8th at 11:59PM.

Programming details.

Your client program must compile from the terminal using GNU C Compiler (gcc) or Java on the undergraduate server attu.cs.washington.edu.

What to hand in.

You will hand in the sequence of server secrets that were received by your client program, along with the source code of your client program and instructions on how to compile and run your code. Please hand in all the materials in a single .tar file that includes all the necessary files, and hand in via catalyst.

Grading.

Partial credit will be given for each of the completed stages of the protocol. The number of secrets that you were able to extract from the server is an indicator of your partial credit score. However, your code will be compiled and re-run against the server. If you were able to extract secrets from the server, your code must compile and be able to extract as many secrets as you have handed in with your assignment.