Copyright Notice: Copyright by CMPUT 379, U. of Alberta, course instructor (E. Elmallah). All rights reserved. Do not post any part on a publicly-available Web site. Example 1 (a2p2-w24-ex1). This example gives sample output of running the server and one client in this order (from two different terminal windows on the same lab workstation). The input file a2p2-w24-exl.dat contains the following lines. # Transactions file for one client # # a2p2 -s a2p2 -c a2p2-w24-ex1.dat 1 gtime 1 put { 1 put { videol.mp4: line 1 videol.mp4: line 2 videol.mp4: line 3 videol.mp4 img1.jpg: line 1 img1.jpg: line 2 1 put indexl.html { img1.jpg indexl.html: line 1 1 put docl.tex { 1 delay 2500 1 gtime 1 quit 1 gtime 1 get videol.mp4 1 get img1.jpg 1 get 1 delete img2.jpg| 1 delay 3000 Sample output (edited for clarity): • Client 1 output: do client (idNumber= 1, inputFile= a2p2-w24-exl.dat) " index2.html Transmitted (src= client:1) GTIME Received (src= server) (TIME: [0]:/ [1] : / Received Transmitted (src= client : 1) (PUT) (video1.mp4) [0]: ' videol.mp4: line 1' [1]: ' videol.mp4: line 2' [2]: videol.mp4: line 3' Received (src= server) (OK) 5.07) Transmitted (src= client: 1) (PUT) (img1.jpg) img1.jpg: line 1' img1.jpg: line 2' (src= server) (OK) Transmitted (src= client: 1) (PUT) (indexl.html) 1 Copyright Notice: Copyright by CMPUT 379, U. of Alberta, course instructor (E. Elmallah). All rights reserved. Do not post any part on a publicly-available Web site. ● [0]: Received (src= server) (OK) indexl.html: line 1' Transmitted (src= client : 1) (PUT) (docl.tex) Received (src= server) (OK) *** Entering a delay period of 2500 msec *** Exiting delay period Transmitted (src= client:1) GTIME Received (src= server) (TIME: Transmitted (src= client: 1) (GET: video1.mp4) Received (src= server) (OK) (videol.mp4) [0]:/ videol.mp4: line 1' [1] : / videol.mp4: line 2' [2]:/ videol.mp4: line 3' Transmitted (src= client: 1) (GET: img1.jpg) Received (src= server) (OK) (img1.jpg) [0]:/ img1.jpg: line 1' [1] : / img1.jpg: line 2' Transmitted (src= client: 1) (GET: index2.html) Received (src= server) (ERROR: object not found) Transmitted (src= client : 1) (DELETE: img2.jpg) Received (src= server) (ERROR: object does not exist) 7.78) *** Entering a delay period of 3000 msec *** Exiting delay period Transmitted (src= client: 1) GTIME Received (src= server) (TIME: 11.00) Server's output (here, the server is terminated manually): a2p2: do_server Received (src= client:1) GTIME Transmitted (src= server) (TIME: [1] : [2]: ' Received (src= client: 1) (PUT) (video1.mp4) [0]:/ videol.mp4: line 1' videol.mp4: line 2′ videol.mp4: line 3' Transmitted (src= server) (OK) 5.07) Received (src= client : 1) (PUT) (img1.jpg) [0]: img1.jpg: line 1' [1]: / img1.jpg: line 2' Transmitted (src= server) (OK) indexl.html: line 1' Transmitted (src= server) (OK) Received (src= client : 1) (PUT) (indexl.html) [0]:/ Received (src= client:1) GTIME Received (src= client : 1) (PUT) (docl.tex) Transmitted (src= server) (OK) 2 Copyright Notice: Copyright by CMPUT 379, U. of Alberta, course instructor (E. Elmallah). All rights reserved. Do not post any part on a publicly-available Web site. Transmitted (src= server) (TIME: Received (src= client : 1) (GET: videol.mp4) Transmitted (src= server) (OK) (video1.mp4) videol.mp4: line 1' videol.mp4: line 2' videol.mp4: line 3' [0]: [1] : [2]: " " 7.78) " Received (src= client : 1) (GET: img1.jpg) Transmitted (src= server) (OK) (img1.jpg) [0]:/ img1.jpg: line 1' [1]: ' img1.jpg: line 2' Received (src= client : 1) (GET: index2.html) Transmitted (src= server) (ERROR: object not found) Received (src= client : 1) (DELETE: img2.jpg) Transmitted (src= server) (ERROR: object does not exist) Received (src= client:1) GTIME Transmitted (src= server) (TIME: 11.00) Important: Don't forget to cleanup the running processes by using the command pkill -u $USER pattern where pattern can be a string that appears in the processes you would like to terminate, e.g., pkill -u $USER a2p2. 3/n Copyright Notice: Copyright by CMPUT 379, U. of Alberta, course instructor (E. Elmallah). All rights reserved. Do not post any part on a publicly-available Web site. CMPUT 379 - Assignment #2 (7%) FIFO-based Client-Server Programming Objectives This programming assignment is intended to give you experience with developing system programs that utilize some of the following UNIX features: signals, threads, timers, pipes, FIFOs, and I/O multiplexing for nonblocking I/O. Part 1 as Program Specifications. This part asks for developing a C/C++ program that can be invoked % a2p1 nLine inputFile delay. When run, the program performs a number of iterations. In each iteration it reads from the input File the next nLine text lines and displays them on the screen. It then immediately enters a delay period for the specified number of delay milliseconds. During the delay period, the program stays responsive to input from the keyboard, as detailed below. After the delay period ends, the program proceeds to the next iteration where it reads and displays the next group of nLine text lines, and then enters another delay period. Subsequent iterations follow the same pattern. More details are given below. 1. At the beginning (and end) of each delay period, the program displays a message to inform the user of its entering (respectively, leaving) a delay period. 2. During a delay period, the program loops on prompting the user to enter a command, and executes the entered command. So, dependin the length of the delay period, the user can enter multiple commands for the program to execute. 3. Each user command is either quit, or some other string that the program tries to execute as a shell command line. The quit command causes the program to terminate and exit to the shell. Other strings are processed by passing them to the shell using the standard I/O library function popen (See, e.g., Section 15.3 of the [APUE 3/E]). 4. Other than forking a child process implied by calling popen (), the program should not fork a child process to achieve the desired behaviour. The process, however, may have threads and/or use timers. Any timer used must work at millisecond-level granularity. ■ Examples. Example output will be posted on eClass. Your output should follow closely the output of the example. ■ Deliverables. Files a2p1-AI-page1.png and a2p1-AI-page2.png (posted online) con- tains code generated by some AI program to handle the above requirements (with no attempt for the output to look like the above example). 1. Answer the following questions in your report. (a) What is the purpose of using SA_RESTART in the code? 1 Copyright Notice: Copyright by CMPUT 379, U. of Alberta, course instructor (E. Elmallah). All rights reserved. Do not post any part on a publicly-available Web site. (b) Does the code satisfy the above requirements? Ignore the differences between the code's output and the given example. If no, identify at least two unsatisfied require- ments. 2. Submit a working C/C++ a2p1 program. Part 2 ■ Program Specifications. You are asked to write a C/C++ program, called a2p2, that can be in- voked either as a server using %a2p2 -s or as a client using %a2p2 -c inputFile Each entity (server or client) has a unique identification number (idNumber). The server's idNumber : 0, and the client's idNumber 1. inputFile contains work that needs to be done by the client. In this part only one client communicates with the server. = Data transfers between the client and the server use FIFOs. A FIFO named fifo-0-1 carries data from the server to the client. Similarly, fifo-1-0 carries data in the reverse direction. = ● Note: For simplicity, FIFOs may be created in the work directory using the shell command mk fifo prior to starting your program development. Context. The client-server system in this part (continued in Part 3) is intended to model a simple file sharing (peer-to-peer) system that allows a community of users to share files contributed by members. In this model system, each user (a client program) uploads files of different objects (e.g., HTML files, images, sound clips, video clips, etc.) to be stored and distributed with the help of a server program. Each object has a unique name and an owner (the client program that succeeds in storing the file at the server). Input File Format The input file has the following format. • A line starting with '#' is a comment line (skipped). Empty lines are skipped. For simplic- ity, an empty line has a single '\n' character. Else, a line that starts with a single digit (idNumber matches one of the following cases: = Note: In this part, we have only one client having idNumber 1, but the descrip- tion below is more general and applies to both this part and Part 3. 1) has format and meaning that - "idNumber (put get|delete) objectName": only the client with the spec- ified idNumber sends to the server the specified get, put, or delete request of the named object. An object name has at most MAXWORD 32 characters. 2 = "idNumber gtime": only the client with the specified idNumber sends to the server a get time request. "idNumber delay x": only the client with the specified idNumber delays read- ing and processing subsequent lines of the input file for an interval of x milliseconds. "idNumber quit": only the client with the specified idNumber should terminate normally. Copyright Notice: Copyright by CMPUT 379, U. of Alberta, course instructor (E. Elmallah). All rights reserved. Do not post any part on a publicly-available Web site. Each "idNumber put objectName" command line is followed by a block that specifies the object contents. Each such a block begins (ends) with a line that starts with the '{' character (respectively, the ' }' character); no other information appears on the line. Inside a block, at most 3 content lines (each has at most 80 characters) may be given. # A fragment of a transactions file # filel is empty 1 put filel { # file2 contains 3 text lines 1 put file2 file2: line 1 file2: line 2 file2: line 3 The server keeps an object table that can store up to NOBJECT= 16 objects (the input File has at most this number of objects). Each object has a name and its content lines. Initially, the object table is empty. Subsequently, as the client executes put (or delete) commands the server updates the table by adding (respectively, deleting) objects form the table. The server replies to a "get objectName" request by sending the stored information to the client (if the object exists in the table). Packet Types Communication in the system uses messages stored in formatted packets. Each packet has a type, and carries a (possibly empty) message. The program should support the following packet types. • PUT, GET, and DELETE: For a specified object name, a client executes a get, put, or delete command by sending a packet of the corresponding type, where the message specifies the object name. An error condition arises at the server when the client's request asks for doing one of the following: – getting a non-existing object, - putting an object that already exists, or - deleting an object owned by another client (this case arises only in Part 3 where multiple clients may exist). • GTIME and TIME: A client processes a get server's time command (gtime) by sending a GTIME packet (with an empty message). The server replies by sending a TIME packet where the message contains the time in seconds (a real number) since the server started operation. • OK and ERROR: The server replies with an OK packet if the received request is processed successfully. Else, the server replies with an ERROR packet with a suitable error description in the message part. 3 Copyright Notice: Copyright by CMPUT 379, U. of Alberta, course instructor (E. Elmallah). All rights reserved. Do not post any part on a publicly-available Web site. The Client Loop The client performs a number of iterations. In each iteration, it reads the next text line from the input file, and executes the specified command only if the client's idNumber matches the one specified on the line. Otherwise, the client ignores the line. The execution of a command depends on its type, as follows: • Commands in the set {put, get, delete, gtime} are executed by sending a packet to the server to do the corresponding operation. The packet contains an object name in the message part, and the object's content lines (for a put command), as applicable. The client then waits for a server's response. • The delay command is for the client to suspend its operation for the specified number of milliseconds (i.e., suspending reading and processing of subsequent input lines, and trans- mitting packets). Note: For simplicity, (and unlike Part 1) here the client is not required to stay responsive to input from the keyboard, or do any other activity, during a delay interval. • The quit command causes the client to terminate normally (and exit to the shell). To monitor progress of the client program, the program is required to print information on • All transmitted and received packets • Received object content (in reply to a GET packet) • when a client enters (and exits) a delay period The Server Loop The server loops on receiving and replying to the client's incoming requests. To monitor progress, the server is required to print information on All transmitted and received packets • Received object content (in a PUT packet) ■ Examples. Example output will be posted on eClass. Your output should follow closely the output of the example. ■ Deliverables. Submit a working C/C++ a2p2 program. Part 3 = In this part you are asked to write a C/C++ program a2p3 that extends program a2p2 so that the server can handle at most NCLIENT 3 clients. Similar to Part 2, the program can be invoked as a server using %a2p2 -S or as a client using %a2p2 -c idNumber inputFile Here, each client idNumber is in the range [1, NCLIENT]. Data transfers between each client and the server use FIFOs (created prior to running the pro- gram): fifo-0-x carries data from the server to client x, and fifo-x-0 carries data in the reverse direction. Input file format and packet types are as described in Part 2. 4 Copyright Notice: Copyright by CMPUT 379, U. of Alberta, course instructor (E. Elmallah). All rights reserved. Do not post any part on a publicly-available Web site. The Server Loop When the program works as a server, it uses I/O multiplexing (e.g., select () or poll ()) to handle I/O from the keyboard and the FIFOs in a nonblocking manner. Each iteration of the main loop performs the following steps: 1. Poll the keyboard for a user command. The user can issue one of the following commands. list: The program writes the stored information about the objects (the idNumber of the owning client, the object name, and the content lines). quit: The program exits normally. ● 2. Poll the incoming FIFOs from the clients. The server handles each incoming packet as described above. To monitor progress of the server, print the information specified in Part 2. Examples. Example output will be posted on eClass. Your output should follow closely the output of the example. ■ Deliverables. Submit a working C/C++ a2p3 program. More Details (all parts) 1. This is an individual assignment. Do not work in groups. 2. Only standard include files and libraries provided when you compile the program using gcc or g++ should be used. 3. Although many details about this assignment are given in this description, there are many other design decisions that are left for you to make. In such cases, you should make rea- sonable design decisions that do not contradict what we have said and do not significantly change the purpose of the assignment. Document such design decisions in your source code, and discuss them in your report. Of course, you may ask questions about this assignment (e.g., in the Discussion Forum) and we may choose to provide more information or provide some clarification. However, the basic requirements of this assignment will not change. 4. When developing and testing your program, make sure you clean up all processes before you logout of a workstation. Marks will be deducted for processes left on workstations. 5. Excused Absences (EAs) for this assignment. Work on this assignment is allocated at least 15 days, and the assignment has three parts. I expect that you start as early as possible on the assignment, and complete and upload a solution to a new part every 5 days (on the average). You can modify your submitted solution archive many times before the due date. If you must miss part (or all) of the assignment then contact me as soon as possible. I typically ask for suitable documentation to substantiate an EA request (EA is a privilege not a right). If granted (and depending on the circumstances), I'll decide on using one of the following two ways. 5