Programming Assignment 3
CS 33600
Network Programming
Spring, 2025

This assignment makes use of the files contained in this zip file. This assignment is due Friday, March 28.

This assignment is based on the two client/server pairs,

from end-of-data.zip. In this assignment you will write four client/server pairs

that implement four more addition protocols.

The addition servers in end-of-data.zip accept a varying number of sequences of integers to add together. Those servers use the end-of-stream (eof) condition to know when there are no more sequences to add up. The addition servers in this assignment will use either a counter or a sentinel to know when there are no more sequences to add up.

Using the end-of-stream condition to denote the end of the sequences has a problem. If the server gets an end-of-stream condition before it sees an expected sentinel, or before it receives a given count of integer values, then the server knows that this is a premature end-of-stream (in the middle of a sequence of integer values), which means that there is a problem with its communication from the client. But if the server gets an end-of-stream condition right after a sentinel, or right after a completed count of integer values (in other words, an eof right after a completed sequence of integer values), then the server assumes that this is a normal, not a premature, end-of-stream. But it may be a premature end-of-stream. The client may still have data to send, but the connection was interrupted. Using end-of-stream to denote the end of all the data is unreliable. The server does not know if it received all the data that the client intended to send. The server just guesses that the client really has sent all of its intended data.

Using either a sentinel value or a count value to denote the end of all the data solves this unreliability issue between the client and the server. If the server gets an end-of-stream condition before the final sentinel, or before the expected number of complete sequences, then the server knows that it has received a premature end-of-stream and that there must be a problem with its connection to the client. (A premature end-of-stream condition can never happen when a program reads from a file. This is another example of how streams over a network do not act like traditional file streams. File streams are assumed to be reliable.)

The servers AdditionServer_v1_Hw3.java and AdditionServer_v2_Hw3.java should both use a sentinel to determine when there are no more sequences expected from the client. The server AdditionServer_v1_Hw3.java should use a counter to know when it has read the last integer in a sequence. The server AdditionServer_v2_Hw3.java should use a sentinel to know when it has read the last integer in a sequence.

The servers AdditionServer_v3_Hw3.java and AdditionSever_v4_Hw3.java should both use a counter to determine when there are no more sequences expected from the client. The server AdditionServer_v3_Hw3.java should use a counter to know when it has read the last integer in a sequence. The server AdditionServer_v4_Hw3.java should use a sentinel to know when it has read the last integer in a sequence.

In summary, the four client/servers pairs should implement the following protocols.

In all of the client server pairs, the sentinel value should be any negative integer.

Here is what three client requests look like for each of the four client/server pairs. 

    4 1 2 3 4 5 -1 -2 -3 -4 -5 3 10 -11 12 -1

    1 2 3 4 -1 1 2 3 4 5 -1 10 11 12 -1 -1

    3 4 1 2 3 4 5 -1 -2 -3 -4 -5 3 10 -11 12

    3 1 2 3 4 -1 1 2 3 4 5 -1 10 11 12 -1

Make sure you understand why each line represents exactly three requests from a single client and make sure that you can determine what numbers are in each request.

The client programs read the data that they send to the server from their standard input stream, System.in.

To make the client-server programs a bit easier to write, the clients should send each integer value to the server on its own line of text, and the servers can expect that each integer they receive is on its own line of text. On the other hand, the clients should handle the input from their standard input stream in a more general way. The clients should use a Scanner to read from System.in, and the clients should expect any number of integer values on any input line (like the sample data above).

As a client reads integer values from its standard input, the client needs to pay attention to those values so that the client knows when it has sent a complete sequence to the server and should wait for a response from the server. (The client should not store all its input data in an array or list. That would be an inefficient waste of computer memory. The client should process each input value immediately after reading it.)

Right after a client sends a completed sequence of integer values to the server, the client should expect back from the server a single message containing the sum of the sequence. After the client gets the server's response, the client can send the next sequence of integer values to the server. Similarly, the server should keep a running total of the values in a sequence and send the final value of the sequence sum back to the client when the sequence is complete. (The server should not store all the received data in an array or list. That would be an inefficient waste of computer memory. The server should process each input value immediately after receiving it.) After the server has sent the client the sum, the server should expect another sequence of integer values.

In the zip file there are data files data_v1.txt, data_v2.txt, data_v3.txt, and data_v4.txt that provide test data for each client/server pair. To use the test data, open a console window and run a server from the command-line. 

   > java AdditionServer_v1_Hw3

Then open another console window and run the companion client from the command-line with the appropriate data file redirected into the client. 

  > java AdditionClient_v1_Hw3  <  data_v1.txt

The resulting output from the client should match data_v1_client_results.txt (except for the pid, ip address, and port numbers) and the resulting output from the server should match data_v1_server_results.txt (except for the pid, ip address, and port numbers).

In the zip file there is a script file, run_tests.cmd, that will automatically run these tests for you, but you need to manually look at the results to see if they are correct.

Make sure you test that your servers can accept multiple connections, one after another. If you have a bug in your server, it might handle its first connection correctly, but then not be able to properly handle a second or third connection.

Turn in a zip file called CS336Hw3Surname.zip (where Surname is your last name) containing your versions of

This assignment is due Friday, March 28.