COE303: Operating Systems, Fall 2022 (250Points)TermRroject Due: 8 January 2023 (23:59) Note: The project can be done in groups of up to 4 students. An on-line Chat System via Network Programming: In this project, you will develop a simple online chat system using sockets in the C programming language. The system will consist of 2 modules: - Client module - Server module Users should be able to send chat messages to each other in plain text using the client module. The server module will mediate the transmission and storage of messages. The server must be able to support multiple users to connect and send messages to cach other at the same time. This assignment is similar to Question 4 in assignment 3, hence you can reuse the codes you have written previously, but with one important difference: If the receiver is online at the time of sending the message (connected to the server via socket and logged in), the server should immediately forward the message to the receiver without waiting. The client, on the other hand, should be able to instantly display the messages that spontaneously come from the server, on the screen. For outgoing and incoming messages, some additional information should also be displayed; i.e., for outgoing messages to whom it was destined to, and for incoming messages, the time of receiving the message and from whom it came should be displayed. For example, the sereen flow after a user starts the client, connects to the server, and logs in might look like this: Session started You have no waiting messages Message sent to all: Hello Al1, how are you? 21:55:04-ali: thank you. If the recipient is offline, the server should store the message for later transmission. Storage of the messages need not be permanent; so you don't need to store messages in a permanent place like a disk or database. There is no harm in deleting messages when the server application is shutdown and started again. Therefore, you can store pending messages in a suitable data structure in memory. Initially the server must be up and running. Clients can connect, log-in and disconnect at different times. The clients will always send the messages and initiate the dialog, while the server will reply to the client appropriately. The client should display messages from other users on its screen, not server responses to his outgoing protocol message (except maybe the first response message upon initial login). The protocol of the chat system will consist of the following messages (the same protocol as in the 3rd Assignment 4th question, with the only difference that there is no POP_MESSAGE protocol message in this protocol): BEGIN_SESSION :The client uses this message to log in. Server: Sends all pending messages (if any) in the user's mailbox to the client. If there are no pending messages, it will reply "You do not have any pending messages". SEND_MESSAGE When a client sends anything other than the above protocol messages, the server should respond with: "Message Not Understood" One particular point you should pay attention to while developing this application should be that the screen on the terminal where the user will perform operations such as logging in, sending messages and logging out, and the message texts that can be sent to him spontaneously by the server should not be intertwined on the screen and should not interfere with each other. Otherwise, no one will want to use your app. You can go for a solution such as managing user interactions, and messages coming from the server in different parts of the same terminal sereen (in UNIX/Linux/MacOS systems it may require using one of the curses or ncurses libraries, which might be a bit tricky); or you can also choose an option such as redirecting them to two different terminals, that is, while the user is managing his own interactions from one terminal, it should be able to follow the messages coming from the server from another terminal. This second terminal should also be opened by your program as soon as the client application is started, and spontaneous messages from the server to the client should be redirected to this second terminal, along with the relevant additional information (time, sender information, message text, etc.). For Unix/Linux/MacOS based systems, after getting the tty (teletypewriter) information of the second terminal (you can get this information with the help of "try" and "Hps u commands via shell, we have seen before how shell commands can be run through exec family system calls from within your program), you can open a file (FILE) in write mode within your program with the name of this tty (for ubuntulinux based systems, for example, "/dev/pts/ttyo", or "/devipts/ttyl", ctc; it may be different in other Operating Systems!) The results of the standard print (fprintf, or write) actions performed towards this file shall be directed directly to that terminal. In this way, the user's inputs and the messuges sent to him from other users will not interfere with each other