Project Overview.
|
This project will introduce you to using the Berkeley sockets API in
the C 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 reserved
and should be set to 0s. 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 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| psecret |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| step | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
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 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 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 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 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 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| secretD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Due Date.
|
NOTE: deadline extended to 24th
The project is due on Friday, October 24th at 11:59PM.
|
Programming details.
|
Your client program must compile from the terminal using GNU C
Compiler (gcc) 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.
|