Project 2: 22C:178 & 055:134
Computer Communications Fall 1998
Project 5 [due 11 December]
The project is a client-server project in which the client can ``recover''
from a simulated server crash. In real applications, clients may be able
to switch to using a secondary server if the primary server is not
responding. For this project, we only use one server, but the problem
is that it stops answering on its TCP port. When this happens, your
client program switches to another TCP port and continues.
The server program uses the following simple logic:
You can view the code for the server:
and study how it communicates with the client. Also,
when you are testing, it may be useful to examine the
that the server reads and writes.
(You will need to have your browser reload
these each time you want to see the latest results.)
Each line in the table shows a student ID number
and the number of times number calculations were
correctly verified in connection A and connection B.
- Most of the time, the server just waits for some
program to contact it on UDP port 6064. The server will be
running on tempest.cs.uiowa.edu (in case this machine
crashes and becomes unavailable, announcements will be posted
on the course web page to specify a replacement machine).
- When the server receives a datagram on port 6064, it checks
that the size of the data is 4 bytes. If the size is not 4 bytes,
it simply ignores the datagram. If the size is 4
bytes, then the server attempts to interpret the data as 4-character
string of numbers representing the last four digits of a student ID number.
The server looks for the student ID number in a table to see if that
number corresponds to some student taking the course.
If the datagram correctly has such a number, then the server writes
a message to a log file containing the number it received.
- In response to receiving a UDP datagram on port 6064 with a valid
number, the server then chooses two random numbers between 5001 and 9999.
These random number will be the TCP ports for further conversation
between client and server. The server sends
these random numbers back to the client using UDP.
Below, we use the first TCP port number for connection A and
the second TCP port number for connection B .
Note: the server sends back the two port numbers in binary,
not as character strings! Thus the client can expect an 8-byte response
to the 4-bytes it sent the server.
The client should then connect to the server,
using TCP, using the connection A port chosen in the previous step.
- The step we now describe is repeated so long as the server desires.
The client reads a 4-byte number using the TCP connection,
and the client sends back a 4-byte number (again, these are binary
integers). Here is the algorithm that the server uses:
- The server generates a random number between 0 and 498.
The server sends this random number to the client.
- The client reads this number, call it x.
The client should then compute the polynomial
(a*x*x*x) + (b*x*x) + (c*x) + d
where a,b, c, d
are the final four digits of the student ID. For instance, if
the last four digits are 4567, then the client will compute
(4*x*x*x) + (5*x*x) + (6*x) + 7
The client then sends the computed number back to the server (again,
as a binary number).
- Since the server knows the student ID from the earlier UDP datagram,
it checks the calculation. If the calculation is correct,
the server writes a message to its log file. The server then
may send another random number to the client and
repeat the test again, as above. However if the calculation appears
incorrect, the server sends the number 1001 back to the client.
- After some random number of iterations of sending to and receiving
from the client, the server ``sleeps'' for 5 seconds to simulate
a crash or some kind of slow server error. After this pause, the
server continues, but uses the connection B port instead of
the connection A port. The client should switch from connection A to
connection B to continue conversing with the server.
- To end this procedure, the server can send the number 1000
to the client: this means the client should close the connection and stop.
- The server can only make a connection with one client at a time.
But this is not a serious limitation, because the server program
limits the total amount of time for all the
steps described above (UDP datagram, TCP conversation) to 20 seconds.
After 20 seconds, the server abruptly closes any TCP connections
that may exist and restarts at the first step.
What to Turn In
Submit your program source by email so that we can
compile it, test it, and verify that it works correctly.
Mail the program to firstname.lastname@example.org and specify
in the subject line, the course number, the project number
and the last four digits of your student ID number (we are
hoping that four digits will be unique). So, for example
if your student number is 123456789, then the
subject line of your email should be:
178 project 5, student 6789
If you do not have such a subject line, I will bounce
the mail back to you for resubmission.
This project counts 150 points maximum. The grading will be
figured from two items, the source you submit and the server
log (from our testing and perhaps your earliere testing).
We can see if your program ran (or at least that some program correctly ran)
from the server log. The server log and table may also be valuable
for us to monitor your progress in completing the assignment.
Note: It is possible that the server can crash, either because
it has a bug or because of some hardware problem.
If you are in doubt about whether the server is properly running
you can test it using the sample client program
which tests the server using student number 9999
(sorry, this program only runs on departmental HP machines).