CMPUT 379编程写作、辅导c/c++

” CMPUT 379编程写作、辅导c/c++CMPUT 379, Assignment 2, Winter 2021University of Alberta / Department of Computing Science(sockets, pthreads, client-server, inotify, synchronization)ObjectiveYou are asked to implement a client/server application. Multiple clients connect to a single server. In thisassignment, the server acts as an intermediary among two kinds of clients. The first kind of client (observer client)monitors a file or directory using the inotify facility (man inotify for more information) and reports to theserver all the changes noticed by inotify on the monitored file/directory. Multiple such clients, each monitoringa different file or directory, and possibly at Different hosts, can be connected to the server at any point in time.The second kind of client (user client) refreshes the screen regularly (similarly to the top command) to display themost recent inotify data reported by each one of the observer clients currently connected to the server.All three roles (server, observer client, user client) are implemented by a single executable notapp) and thespecific role is controlled by the flags and arguments passed to it. Specifically:server:notapp -s -t interval [-p sport] [-l logfile]observer client:notapp -o saddr sport fileordiruser client:notapp -u saddr sportWhere interval indicates how frequently the server broadcasts to the user clients the most recent events ofits observer clients. The interval can take values from 0.1 to 10 seconds. The sport is the server port and itis optional. If not provided, the system chooses a port for the server. This port (the chosen by the system) shouldbe printed by the server to stdout before it becomes a daemon process. The logfile is an optional log filewhere the server keeps track of all the messages it received and any of the actions that it took. The log file ismeant mainly for debugging, so it has to be informative to you and the teaching assistants.When starting as a client of either type (observer or user), the client connects to the server listening on portsport of the host with saddr IP address. In the case of an observer client, the fileordir indicates the fileor directory to monitor for all possible inotify events.Observer Client BehaviorThe observer is a producer of information and, as such, does not need to consume information coming from theserver. Rather, it provides information to the server. The observer monitors the file or directory indicated for all2 / 4possible inotify events, and it reports those events to the server. There is no strong requirement to use multiplethreads for an observer client (or any client for that matter), although one could use them to good advantage. Ata minimum, the first message from a client to the server should allow the server to distinguish whether a client isan observer or a user client, and, if it is an Observer client, what is the file or directory that the particuar observeris monitoring. There are three requirements for observer clients: a) to send each inotify_event information assoon as possible to the server, i.e., to not delay it unnecessarily, b) to annotate each such information with thelocal timestamp when it happened (in microsecond accuracy, see man gettimeofday), and c) to gracefullyterminate and let the server know it terminated when either (i) the file or directory being monitored is removed,or (ii) it receives a SIGINT signal. The observer client does not depend on any user terminal input, so it should bepossible to let it run as a background process. It should not produce output to stdout. Finally, for simplicity,monitoring of directory should not be Recursive.User Client BehaviorThe user client, after connecting to the server, periodically refreshes the screen and (assuming N observers areconnected to the server at that point) it displays the most recent inotify event sent by each of the N observersto the server, sorted in order of timestamps. The output is one line for each of the N observers. The server,recognizes (see comment for Observer Client Behavior) that it is talking to a user client. The server pushes to theclient, every interval seconds, the updated list of most recent event from each of the observer clients.Therefore, the user client is expected to refresh the screen with the most recent events once every intervalseconds. Note that N changes over time and, hence, there might be more, or fewer, lines from one instant to thenext. The user client is supposed to do minimal work, i.e., just the rendering of the information sent from theserver. The user client should terminate when receiving a control-C, but it should do so gracefully, by notifyingthe server that it is terminating.User Client Output FormatThe format of the lines displayed by user clients follows the format of this example (with N=3). Upper left is upperleft of the terminal screen. Notice that they are sorted by timestamp with the most recent at the top:TIME HOST MONITORED EVENT1612142039.611365 192.168.0.3 myDir f.txt IN_ACCESS1612142019.855106 192.168.0.10 /tmp src IN_CREATE IN_ISDIR1612142000.471291 127.0.0.1 a.txt IN_ATTRIBThe time is in the format of seconds followed by a period followed by microseconds (consult mangettimeofday). HOST is the IP address of the host on which the corresponding observer is running. MONITORED isthe monitored file or directory. In this example, the last observer in the list happens to be monitoring a file(a.txt) while the two others are directories. The EVENT is the information conveyed in the event mask in humanreadable form (see man inotify for the names). If the observer is monitoring a directory, then EVENT is prefixedby the name of the relevant file or directory within the monitored directory (see name member in structinotify_event). In the above examples, Someone changed an attribute (e.g., chmod) on a.txt; a subdirectorynamed src was created within /tmp; file f.txt (which is inside directory myDir) was read.3 / 4Server BehaviorThe server binds to the port, it becomes a daemon process, and waits for connections from the clients. In theinitial handshake with the client it has to determine whether a client is an observer or a user client. Noassumptions can be made that all observers (or any observer) connect first. Either kind of client might wish toconnect (or gracefully terminate the connection) to the server at any point in time. The server is responsible forkeeping track of the clients. It is a requirement that each new cleint connection to the server is handled by aseparate pthread. The thread should be terminated when the corresponding connection terminates.The server works in the following fashion: a) it collects, as quickly as possible, data received from the observerclients and updates a common data structure which stores the most recent event that came from each observer. Ifa logfile was specified, the server also dumps the received events to the log file, in the order they are received. b)The threads serving the user clients are periodically (with interval period) sending the updated informationof this common data structure to their corresponding user clients, so that it can be rendered. It is expected that ifthere are M user clients connected at the moment the periodic update is triggered, all M clients receiveconsistent, i.e., identical, information. In Other words, the threads serving the user clients broadcast the currentstate of most recent events to all simultaneously connected user clients. It is expected that the server handles theterminating clients in a graceful manner, i.e., without crashes or undue delays. Finally note that the common datastructure at the server may be accessed by multiple threads at the same time. You will need to use concurrencycontrol for its access.There is no specific requirement for the protocol format between clients and server. However, you have todocument what is the protocol you use (what messages you are sending and/or expecting).RefinementA requirement is to add one more refinement to your code. There are two possible refinements from which youcan choose.Server timestampsThe clocks of different hosts are not synchronized, therefore timestamps of observers from different hosts can beinconsistent (e.g., something might arrive later from another host but have an earlier timestamp than a currentevent on our host). Introduce a compilation flag that forces the server to ignore the timestamp associated withthe events sent from the observers and instead uses its own local (at the host where the server is running)timestamps. These timestamps are of the time instant the server received the corresponding event.Fresh info visualizationBetween two broadcasts there might be more than one event from an observer. This is easily handled by havingthe server store the most recent event (overwriting the previous event) coming from that observer. Theimplication is that you might not see some of the events reported by the user clients if a more recent event forthe same observer has occurred within the interval. This is to be expected and it is correct. There could also beintervals where no new events have been observed by one or more observers. In this case the user server willbroadcast (and the user client will render) the same most recent event information for the observers that hadnothing new. (And the new information for those observers who had more recent events.) Introduce a4 / 4compilation flag to add boldface font to the lines representing new recent event from the correspondingobserver.DeliverablesThe language of implementation is C. You are expected to deliver good quality, efficient, modular,documented, code. That is, the quality of your code will be marked.Your assignment should be submitted as a single compressed (zip or tar.gz) archive file. The archive shouldcontain all necessary source files as well as a Makefile. Calling make without any arguments should generate thenotapp executable. Your submission must include the DESIGN.md (plain text or markdown format) documentwhich: (a) describes your protocol between clients and server, and (b) indicates which refinement youimplemented. Refinement executables should be Produced by issuing make notapp.time or make notapp.bold(depending on which refinement you decided to implement).In the lab machines, always remember to terminate any processes you have left running before leaving orlogging out your ssh session, and in general before you turn your attention to some other task. Generally,ensure that you have not left any stray processes running on the physical machine before leaving. Violations ofthis rule may be penalized with mark Deductions. Furthermore, the system administrators have been givenpermission to terminate such processes and to report to the instructor the users who left them running.Monday, February 1st, 2021如有需要，请加QQ：99515681 或WX：codehelp

“