Client–server model is a distributed application structure that partitions tasks or
workloads between the providers of a resource or service, called servers, and
service requesters, called clients. Often clients and servers communicate over
a computer network on separate hardware, but both client and server may reside in
the same system. A server host runs one or more server programs, which share
their resources with clients. A client does not share any of its resources, but it
requests content or service from a server. Clients therefore initiate communication
sessions with servers, which await incoming requests. Examples of computer
applications that use the client–server model are Email, network printing, and
the World Wide Web.
You are to implement a client-server architecture. The clients receive transactions that they
pass on to the server. Think of a client as a web page where a user initiates a transaction (such as purchasing an airline ticket). The request gets sent to a server (the airline company) for processing. This is shown in the following diagram
For this assignment you will implement a client-server architecture. Clients generate transactions (T) that get sent to the server to execute. Clients may have lulls between transactions, so they wait (S) for a transaction to happen. The server receives the transactions, processes them, and then waits for the next transaction.
You will write a program called server that accepts one command-line argument:
where port is the port number that the server listens to for communications from clients. The
port must be in the range 5,000 to 64,000.
You will also write a program called client that accepts two command line arguments:
client port ip-address
where ip-address is the IP (Internet Protocol) address of the machine that is hosting the
server, and port is the port number that the server will read from (in the range 5000 to
64,000, the same number that the server uses).
For example, executing the command
on machine ug11 (IP address 220.127.116.11) results in the server listening for messages on port 6000. When a message is received, it will process it and then wait for another message. Executing the following command on ug12 ./client 6000 18.104.22.168 and S commands. The T commands get sent to the server to be executed, while the S command causes the client to wait. Note that you can have multiple clients on multiple machines, all sending to the same server. Try it! More specifically, a client process receives input (either from the keyboard or redirected from a file) containing two commands:
T Transaction. The parameter is an integer > 0. This command will be sent to the server for processing. The client sits idle waiting for the server to complete the transaction. S Sleep. This command simulates having the client wait between receiving new transactions to process. The client waits for a time determined by integer parameter n, with n between 0 and 100. You will have a routine that gets called for each sleep request: void Sleep(int n).
The server process reads its input from the port number specified on its command line invocation. Specifically, these messages from clients are transaction requests: T Execute a transaction with integer parameter n, with n > 0. You will have a routine that gets called for each transaction: void Trans(int n). The parameter n is used by Trans to determine how long to simulate the execution of the transaction. We will guarantee that the input files used are in the correct format. The code for Trans and Sleep is available on eclass (same as Assignment 2). Do not change these functions!
The server maintains a transaction # that starts at 0 and is incremented with each transaction performed by the server. When a transaction is complete, the server sends back to the client the message D, that the transaction is “D”one, and that its transaction number is n. When the client reaches the end of input, then it will exit. The server, by definition, does not exit – it does not know all the potential clients that might try to communicate with it.
Note the following in the output below:
• Log file times are actual times (UNIX Epoch times), with two decimal places for the
partial seconds. Epoch times can be converted to normal dates, for example using the
converter at www.epochconverter.com.
• Each client records all its Trans calls – when sent to the server and when the server
acknowledges that the transaction is complete.
• Each client records when it does a Sleep.
• In the log file, T=Trans, S=Sleep, and D=Done.
• The server gives each transaction it receives a unique # (starting at 1). The server puts
the transaction number in its log file, and sends the transaction number back to the
client (a receipt acknowledging completion of the transaction).
• The semantics of T and S events are exactly the same as in Assignment 2.
• Clients do not do any work between the sending of a transaction request (T) to the
server and the acknowledgement that the transaction is done (D). In the real world, the
client might itself be a multi-threaded program, dealing with other requests while it
waits for a transaction to complete (that is NOT part of this assignment).
• Note the impact of long transactions on the client and on the server. Some of this
overhead could be mitigated if the server was multi-threaded (as in Assignment 2), but
that is NOT part of this assignment.
DescriptionIn this final assignment, the students will demonstrate their ability to apply two ma
Path finding involves finding a path from A to B. Typically we want the path to have certain properties,such as being the shortest or to avoid going t
Develop a program to emulate a purchase transaction at a retail store. Thisprogram will have two classes, a LineItem class and a Transaction class. Th
1 Project 1 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of
1 Project 2 Introduction - the SeaPort Project series For this set of projects for the course, we wish to simulate some of the aspects of a number of