The objective of this assignment is to familiarize you with UNIX socket programming. It is an individual assignment and no collaborations are allowed. Any cheating will result in an automatic F in the course (not just in the assignment). If you have any doubts/questions, post your questions on D2L. You must discuss all project related issues on the Piazza discussion forum. We will give those who actively help others out by answering questions on the Piazza discussion forum up to 10 bonus points.

Problem Statement:

Library  Management  Systems  are  essential  for  efficient  library  operations.  They  organize resources,   improve   accessibility,   automate   tasks,   and   provide   valuable   data   for   better decision-making.  Library  Management   Systems  streamline  library  services,  save  time,  and enhance the overall user experience. This can also empower library staff with valuable insights into the inventory, highlighting books that frequently run out of stock. This information aids in effective  inventory  management  and  allows  for  the  timely  ordering  of high-demand  books, thereby  optimizing  the  library's  response  to user requests. Additionally, security is a critical aspect   to   address.   Ensuring   that   our   Library   Management   System   incorporates   proper authorization  mechanisms,  such  as  requiring  usernames  and  passwords,  are  crucial. Without these safeguards, non-members could potentially borrow books without paying the membership fee.  Therefore,  the  development  of  a   secure,   reliable,   functional,   and   informative  web registration system is paramount for our library's success.

In this project, you will implement a straightforward library registration system. To simplify our library's  organization,  we  will  divide  it  into  three  distinct  departments,  each  dedicated  to  a specific genre of books: Science, Literature, and History.

This system will enable users to submit the book code of their desired book, check its availability within the relevant department, and proceed with borrowing if the book is available.

Specifically, a library member will use the client to access the central library registration server, which  will  forward  their  requests  to  the  department  servers  in  each  department.  For  each department,  the  department  server  will  store  the  information  of  the  books  offered  in  this department.  Additionally,  the  main  server  will  be  used  to  verify  the  identity  of the  library member.

Figure 1: Illustration of the system

The backend servers will access corresponding files on disk and respond to the request from  the  main  server  based  on  the  file  content.  It  is  important  to  note  that only the corresponding server should access the file. It is prohibited to access a file on the main server or other servers. We will use both TCP and UDP connections. However, we assume that all the UDP packages will be received without any error.

Source Code Files

Your  implementation  should  include  the  source  code  files  described  below,  for  each component of the system.

1.  serverM (Main Server): You must name your code file: serverM.c or serverM.cc or  serverM.cpp  (all  small  letters  except  ‘M’).  Also,  you  must  include  the corresponding header file (if you have one; it is not mandatory) serverM.h (all small letters except ‘M’).

2.  Backend-Servers S, L, H: You must use one of these names for this piece of code: server#.c or server#.cc or server#.cpp (all small letters except for #). Also, you must include the corresponding header file (if you have one; it is not mandatory). server#.h (all small letters, except for #). The “#” character must be replaced by the server identifier (i.e. A or B), depending on the server it corresponds to. (e.g., serverA.cpp & serverB.cpp)

Note: You are not allowed to use one executable for all four servers (i.e. a “fork” based implementation).

3.  Client: The name of this piece of code must be client.c or client.cc or client.cpp (all small letters) and the header file (ifyou have one; it is not mandatory) must be called client.h (all small letters).

Input Files:

member.txt:  contains  encrypted  usernames  and  passwords.  This  file  should  only  be accessed by the Main server.

science.txt: contains science book inventory information categorized in book code, and number of the available books. different categories are separated by a comma. This file should only be accessed by the Science Department server.

literature.txt: contains literature book inventory information categorized in book code, and number of the available books. different categories are separated by a comma. This file should only be accessed by the Literature Department server.

history.txt:  contains  history  book  inventory  information  categorized  in book code and number of available books. different categories are separated by a comma. This file should only be accessed by the History Department server.

Note: member_unencrypted.txt is the unencrypted version of member.txt, which is provided for your  reference  to  enter  a  valid  username  and  password.  It  should  NOT  be  touched  by  any servers!!!

Phase 1: Boot-up

Please refer to the “Process Flow” section to start your programs in order of the main server, server  S, server L,  server H, and Client. Your programs must start in this order. Each of the servers and the client have boot-up messages which have to be printed on screen, please refer to the on-screen messages section for further information.

When three backend servers (server S, server L, and server H) are up and running, each backend server should read the corresponding input file (science.txt, literature.txt and history.txt) and store  the  information  in  a  certain  data  structure.  You  can  choose  any  data  structure  that accommodates the needs. After storing all the data, server S, server L and server H should then

./client

(Please refer to the on-screen messages)

Please enter the username: <unencrypted_username>

Please enter the password: <unencrypted_password>

This unencrypted information will be encrypted at client side and then sent to the main server over TCP.

Phase 2B: Main server receives encrypted username and password from the client. ServerM sends the result of the authentication request to client over a TCP connection.

If the login information was not correct/found:

./client

(Please refer to the on-screen messages)

Failed login. Invalid username/password

Please enter the username: <unencrypted_username>

Please enter the password: <unencrypted_password>

After the successful login:

./client

Please enter the book-code: <bookcode>

Phase 3: Forwarding request to Backend Servers

Upon user input of a book code, the client is responsible for transmitting the request to the server M that is to the Main server via a TCP connection. The server M parses the received bookcode to determine the appropriate destination server for request forwarding.

Specifically, when the book code commences with "S," the request must be routed to Server S.     Similarly, if the bookcode initiates with "L," the request is directed to Server L. In the event that  the bookcode originates with "H," the request must be forwarded to Server H.  All the valid book codes are eligible for forwarding to theirrespective servers from the Server M via a UDP connection.

Note: Each server will have a dedicated database file. This file should be read only once at server startup to ensure that if a user checks out a book, the corresponding book's inventory count is

updated accurately in the respective data structure and must not be overwritten by reading the database file over and over.

Phase 4: Reply

The corresponding genre server will check its input file and find the count of the requested

book-code. If the count is greater than 0, then the respective server will reply to the main server   using UDP - “The requested book is available”. And if the count of the book is 0, then the server will reply to the main server using UDP - “The requested book is not available”. It is also

possible that the book-code entered by the client is not there in the system, in that case, the server will respond with a message - “Not able to find the book”. Also after sending the reply to the

main server the genre server will decrement the count of the corresponding book-code by 1 in the file so that when a client requests a book a second time, the availability is updated and correct in  the file.

And at last, the main server will print the on-screen message and will forward the reply from the genre server to the client using TCP. And the client will print the on screen message which gives the availability of the requested book-code.

See ON SCREEN messages table for details.

Extra credit: Inventory Management

In this section, we will empower library staff to access information about the total availability of books based on theirrespective codes. To do this, a staff member can login using the following   credentials: Username: Admin, Password: Admin. Once authenticated, the staff can enter a book code, and the system will display the total number of copies available in the library's inventory    for that specific code.

Process Flow/ Sequence of Operations:

●   Your project grader will start the servers in this sequence: ServerM, ServerS, ServerL and client in 4 different terminals.

●   Once  all  the  ends  are  started, the  servers and clients  should be continuously running unless stopped manually by the grader or meet certain conditions as mentioned before.

Required Port Number Allocation

The ports to be used by the clients and the servers for the exercise are specified in the following table:

Note: Major points will be lost if the port allocation is not as per the below description.

NOTE: xxx is the last 3 digits of your USC ID. For example, if the last 3 digits of your  USC  ID  are  “319”,  you  should  use  the  port:  41000+319  =  41319  for  the Backend-Server (A). It is NOT going to be 41000319. Note that the serverM has only one UDP port. The same port is used to connect to all of the backend servers.