In this week's assignment, you will study ways of handling concurrent clients. You also learn about their strengths and complications.
Using the South University Online Library or the Internet, research the ways of handling concurrent clients.
Consider the following situation:
In the distributed books library application, each client on registering itself with the server can serve its books, download books, and browse available books. If a client is registered to serve one or more books, then it acts as a server with a listening port.
Based on your research and week's readings, continue with the Microsoft Word document from W2 Assignment 2 and add a 3- to 4-page report to complete the following tasks:
Discuss how you will design the server in the given situation to handle multiple clients arbitrarily entering and leaving the system? Describe your server design in detail.
Justify your design selection.
Include a simple block diagram to describe the components of your design.
Perl is the language selected for doing this assignment. If you are asked to pick a different language, which language would you choose for implementing your design? How is compared to Perl?
When it comes to implementing your suggested design, describe what the most challenging task is. Why do you think so?
This material may consist of step-by-step explanations on how to solve a problem or examples of proper writing, including the use of citations, references, bibliographies, and formatting. This material is made available for the sole purpose of studying and learning - misuse is strictly forbidden.
* Server design for the distributed book library application.
* I will use prethreading architecture
* The prethreading server creates many threads to deal with future connections. They will call accept() function.
* The main thread will launch new threads when the loading amount increases on the server and delete excess threads when the load diminishes.
* In order to achieve that goal, we will maintains a global %STATUS hash that is monitored by the main server thread and updated by each thread. Since the threads are all running in the same process, they can modify %STATUS directly, all thread have to take appropriate steps to synchronize their access to the hash by locking it before modifying it.
* The keys of %STATUS are one of the strings "busy," "idle," or "goner."
• Each worker thread's accept() loop invokes status() to change the status of the current thread to "idle" before calling accept() and to "busy" after it accepts a connection.
• “gonner” will be discuss later
* To simplify the management of %STATUS, we use a small subroutine named status() that allows threads to examine and change the hash in a thread-safe manner.
* The main thread monitors changes to %STATUS and acts on them. Each time through the main thread's loop, it calls cond_wait() on the condition variable, putting itself to sleep until one of the worker threads indicates that the variable has changed. status() subroutine calls cond_broadcast() whenever a thread updates %STATUS, waking up the main thread and allowing it to manage the change.
* In order to shut down gracefully, the server responds to the TERM and INT signals by shutting down, the main thread changes %STATUS into value of “goner”. Each worker periodically check its status code for a special value of "goner" and then exit. To decommission a worker, the master simply calls status() to set the worker's status code appropriately....