Project 2

Project Overview.
In Project 2, you will be writing a web server that can handle clients communicating in a specific protocol. Your server's task is to verify whether the client adheres to the protocol and send a response only to the valid client. Your server should handle multiple clients at a time.

Sample client: client
Revised Sample Client: client

Protocol.

We will follow the same protocol as project 1 and hence you can use your client from project 1 to verify your server. The server should receive and send only:
  • payload that has a header (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)
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.

Server:
  1. The server should handle multiple clients at a time. This can be done using threading. Spawn a seperate thread for every new client and kill the thread when the client finishes.
  2. The server should verify the header of every packet received and 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
    • the server does not receive the correct secret
  3. The Server should respond to the client in four stages.In each stage, the server should randomly generate a secret to be sent to the client.

STAGE a:
Step a1. The client sends a single UDP packet containing the string "hello world" without the quotation marks to your server 

 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                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The server should verify the payload and respond with a UDP packet containing four integers: num, len, udp_port, secretA. All these numbers should be randomly generated.Then your server must wait for the client's packet at udp_port. 
 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 will transmit num UDP packets to the server on port udp_port.The server has to verify that
  • 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 is the 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) is 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 randomly decides whether to 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                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The server should receive the same packet again if it decides to not send an ack.(Make sure your server does not send an ack atleast once for the entire transaction). This step will complete after the server receives num packets correctly in order.

Step b2. Once the server receives all num packets, it should send a UDP packet containing two integers: a TCP port number, secretB. Now the server should wait for a TCP connection from the client at TCP port number. 

 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 will open a TCP connection to the server on port tcp_port received from your server in step b2.

Step c2. Your server should then send 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 should respond 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 22nd at 11:59PM.

Programming details.

Your server program must compile from the terminal using GNU C Compiler (gcc) or Java.

What to hand in.

You will hand in the source code of your server 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. Your code will be compiled and re-run with our client.