ITERATIVE_SOCKET_SERVER_REPORT

.docx

School

University of North Florida *

*We aren’t endorsed by this school

Course

4504

Subject

Information Systems

Date

Jan 9, 2024

Type

docx

Pages

Uploaded by DeanWalrusPerson947

ITERATIVE SOCKET SERVER CNT 4504: Computer Networks and Distributed Processes

INTRODUCTION The purpose behind this project was to create an iterative socket server program that took client requests, and then analyze how using a single-threaded client-server configuration would process these requests. An iterative server takes requests from a client and responds to them one at a time. It has to fully process and respond to a request before it can process and respond to the next ones. The main goal behind this project was to learn the basics of connecting a server application to a client application for a knowledge base that could be used in future endeavors on a job site. In this paper, readers can expect to read about the setup of the programs and their design, how data was tested and collected from these programs, and what conclusions were drawn about hoe client requests were processed. CLIENT-SERVER SETUP AND CONFIGURATION Two programs were created- the first one was the iterative server that took requests from the client, and the second one was the multi-threaded client that created multiple client sessions connecting to the server. For the iterative server side, it was designed to take and display the following inputs: date and time, uptime, memory use, netstat, current users, and running processes. These were the stats from the server that the client needed to know while they made their requests. It was written within a try with resources so that it would only run if a functional server was created. Switch statements were utilized to determine which actions to perform because it kept the program more organized than using another form, such as if statements. All functions were fulfilled by calling Linux commands using the “Runtime.getRuntime().exec()” method. While some functions could have been fulfilled using other Java classes, it would have required the importation of additional libraries and the creation of additional objects. Using Linux commands for every function kept the code more simple and likely more efficient. Finally, in order to get the client to look for a specific line to figure out when it reaches the end of the input of a request, an additional line was added after the server writes its final line of data to the client. Overall, this configuration allowed the program to have easy readability, kept it organized, made it easy to fulfill commands, and kept it working in the most efficient way possible to satisfy all requirements of the project. For the client side, it was created to listen for client requests, listen to how many clients needed to be sent to the server, send the requests to the server, print the results from the server, and calculate data such as the total and individual turnaround times of each set of clients. This was also where a majority of the data that was going to be tested and analyzed would appear. This program needed to be threaded, and this was accomplished by creating an additional class that extended the original Thread class named “ClientThread”. It allowed requests to the server to be made, read the information that was delivered back, and stored the total turnaround time of a set of information using a static variable. To use this class in the easiest way possible, a helper method located within the “Client2” class, named “makeRequest”, was created to build arrays of ClientThreads of a specified length and request type. It also ran these threads and made sure they ran to completion before moving on to the next part of the program. Once it ensured that all of

the threads completed, it called a method within the ClientThread class that returned the value of the static variable that held the accumulated the runtimes of all the clients of the set and reset it to zero. With this information, the helper method calculated and printed the average turnaround time. There is a loop that the client uses within the extended Thread class that is used to read information that came from the server. In order to break out of the loop, it looks for the final line of data the server side created and sent to indicate that the client is at the end of the input. Similar to the server side, it was written within a try with resources to ensure that it would only run if it could connect to a functional server. This allowed the client side to effectively work to gather data and fulfill requests while keeping the program easy to read and set up in a way that promotes organizational efficiency. TESTING AND DATA COLLECTION In order to test the iterative server that was created, they were compiled using Bitvise and FortiClient. FortiClient was used to connect to an SSH VPN client, then both client and server programs were uploaded and compiled to respective servers, and once the programs were launched, they worked together to take client input and produce corresponding output. The server side communicated with the client side, which is where it asked the user to specify the request it wanted to make (show data from uptime, memory use, netstat, etc.). Once the request was made, the program then asked how many clients the user wants to test. The client side would send this information to the server side, and if all the requirements were fulfilled then it would send the data back to the client side and display the information the user requested. The server side would remain idle until another request was made, and the client side would display the data until new information was sent over. From the six operations that were tested, six client groups were tested in each category. The operations were date and time, server uptime, memory usage, netstat, the number of current users, and the number of running processes. Each operation was tested with one client, five clients, ten clients, fifteen clients, twenty clients, and then twenty-five clients. The turnaround times for each individual client was recorded along with the total turnaround time and average turnaround times of the category as a whole. For example, when the operation date and time was performed and five clients was the selected test amount, five groups of personalized data were produced and recorded, and the total and average turnaround times were displayed at the end of the program as a total analysis of the five clients as a whole. This was the method used to test all operations against the number of clients that were selected.

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help