Protocol standard for this project: Client Command DISCONNECT CONNECT:account_no GET_PRODUCTS GET_ORDERS Server Response No response. The server removes the client from the list of active clients. Both sides end the connection. CONNECTED:user_name The client has successfully connected with the specified account number. The server returns the connected client's name. CONNECT_ERROR The client's connection attempt is unsuccessful. The account_no is not valid. PRODUCTS: product_name1,quantity1|product_name2,quantity2|... The server sends all product information (e.g. PRODUCTS:APPLE,2 | ORANGE, 1). NOT CONNECTED The client is not currently connected. ORDERS:product_name1,quantity1,user_name|product_name2,quantity2, user_name[... The server sends the purchase orders of the current client. (e.g. ORDERS:APPLE,1,John | ORANGE,1,Doe). NOT CONNECTED The client is not currently connected. The product_name argument is one of the product names from the GET_PRODUCTS response. NOT AVAILABLE The product is not available (i.e., is already purchased by another client) and cannot be PURCHASE:product_name purchase. NOT_VALID The specified product is not valid. NOT_CONNECTED The client is not currently connected. Develop a shopping solution that has both client side and server side. Server-side ⚫ A console application should be enough, it prints each response to the output window before sending back to the client-side(s). • When it first runs, at least five pre-defined products with random quantities (1-3) should be initialized. Which means products should be the same every time the server starts, and the quantities for each product should be randomized. At least 3 accounts should be created, each account has an account number and user's name. • When the server is active, it should store ordering information to variable(s) (e.g., dictionaries, lists). The server does not have to store the ordering information to the local system, so once you shutdown the server, all information can be disposed. • Server should send back appropriate response depending on the client's command. (Protocol below) • The handler code should be separated from the user interface (i.e., in a separate class - similar to the examples on My.Seneca). • The server must be able to talk with multiple clients at the same time Client-side • The client-side should be a Windows Forms application, with an appropriate user interface. The user can select one product, then make the purchase. (quantity as one) • • When it first opens, a login form should appear with two input fields: hostname/IP and the account number. (localhost as the default value for the hostname) If the server cannot be found, the application should display an error message; if the server is active but login failed, a different error message should be displayed. • Once the user successfully connected to the server, the application should get all products information (names and quantities), then show all information on the GUI. • • The user must be able to gracefully disconnect from the server. Upon disconnecting, the application should close. The application should gracefully disconnect when the form is closed. When the user making the purchase, if the product is not available, the application should display an appropriate message stating that the product is no longer available. • The application should be able to show current purchase orders. • The server handler code should be separated from the user interface (i.e., in a separate class- similar to the examples on My.Seneca). • The application must ensure that code that writes to or reads from the server does not block the GUI thread. You may choose either use multithreading or asynchronous programming to prevent blocking of the GUI thread.