Comparison of TCP and UDP Client-Server APIs
Goal of the project
The goal of this project is to compare Java API for client-server development. Specifically, you will compare Java Socket API and the Java Datagram API. These API’s will be compared from a programmer’s standpoint as well as an architectural standpoint. Thus, you will need to compare the performance obtained in each case (quantitative comparison), as well as make a qualitative comparison. While discussing the quantitative results obtained, back your conclusions with data to support your conclusions. Try to answer why you feel technique A is faster than technique B etc.
In addition, you will compare these APIs, based on your observations, in relation to the ease of understanding the technology; time required for development, difficulties encountered, stability of code etc. This list is not meant to be exhaustive. Be sure to include any pertinent conclusions based on your experiences.
Description of the Client-server interaction
You will implement a reliable FTP client-server system.
Provide a simple menu to the user, e.g.
GET
PUT
CD
QUIT
Your code must be robust and handle any incorrect user input. Since there can be multiple clients querying the server at the same time with each client being serviced by a different thread on the server, the server must ensure concurrency control on the data file while it is being updated. Thus, only one thread must gain access to the data file during writes (hint: use synchronized keyword for the write method in your code).
Be sure to terminate each thread cleanly after each client request has been serviced.
Project 1
Implement the project as described using Java Sockets (TCP). This will be a connection- oriented client-server system with reliability built-in since TCP provides guaranteed delivery.
Project 2
Implement the project as described using Java Datagrams (UDP). This will be a
connectionless client-server system since UDP is connectionless. However, you will need to provide reliability in your client-side application code since UDP does not guarantee
delivery.
In each project, be sure to measure the mean response time for the server to service the client request. To graph this, have your client make requests in the order of the following data/file sizes: 1 MB, 25 MB, 50 MB, 100 MB. First do this for the PUT command and then do this for the GET command. Determine the response time in each case, then plot the response time vs. offered load (file size) graph.
Next, plot the throughout versus offered load graph using the data from the GET graph/command. Throughput in this case is bytes delivered per second (bytes/second). Plot the bytes/second on the y-axis and offered load on the x-axis. So, at the end of each project, you will have 3 graphs: one graph for the response time for the GET command, one graph for the response time for the PUT command, and the throughput graph for the GET command.
Have your server print out diagnostic messages about what it is doing (e.g., “accepting a new connection”, etc.) Your code will be expected to deal with invalid user commands.
