CS 240 Spring Semester 2021 Assignment 3 In Visual Studio 2019. Course weighting 12.5% This is an individual assignment. No collaboration is permitted. Task 1. [20 points] Modify your Math Practice...

Attached is the task. It has total 3 short coding in visual studio 2019, C++/CLI. This is coding in C++/CLI in visual studio 2019. Each task should be saved in their own folder. Submit in a sub folder for each task. Do not copy from online, it has to be your own. Also please provide screenshot of each tasks after its complied and run for submission. Thank you!


CS 240 Spring Semester 2021 Assignment 3 In Visual Studio 2019. Course weighting 12.5% This is an individual assignment. No collaboration is permitted. Task 1.[20 points] Modify your Math Practice GUI program to use a client-server architecture with a multithreaded server using TCP sockets. The client side will use the graphical user interface you have implemented, but any most of the processing including generating numbers selecting operation symbols, and calculations comparison with user result etc will be on the server side. The server will be a console application without graphical user interface. In order for the client and server to communicate, you may use the following application level protocol: · The communication between the client and the server happens in sessions. Each session begins with the client requesting a connection to the server, followed by a series of client commands (requests for service) and server responses. The last command for each session is “QUIT ”, which is a request to end the session. · Client sends commands to the server and after each command expects a response line. · You should design the possible sequences of commands and describe them in your report. · Example commands: · Add · Subtract < number=""> · Generate · QUIT · Server performs the received commands one at a time and sends a response after processing each command. Task 2 [20 points] Change your program to use UDP connection. Task 3: [80 points] Design and implement a reliable application-level protocol, capable of handling the following errors: · Error: wrong part of a message (for example, text instead of number) · Loss: missing part of a message (for example, an operand of the requested operation) · Delay: a message or part of it (for example, the result of an operation) does not arrive in a “reasonable” time interval To be able to demonstrate handling of such errors, break the commands from Task 1 to parts. For example, instead of sending one message: Add send three messages: Add and simulate unreliable connection by sometimes sending a wrong operand or result (error), sometimes omitting or delaying an operand or result (loss or delay), with settable probabilities. For example, a correct operand is sent in 50% of the requests, but a wrong operand is sent in the other 50% of the requests; an expected operand or result is sent in 75% of requests, but omitted in 25% in the requests; an expected piece of data is sent with a significant delay in 25% of requests, etc. To facilitate easy testing, please allow the user to set these probabilities through the GUI of the client side of the application. To handle errors, you can use the ideas of Transport layer error-handling protocols (ACK/NAK or a NAK-Free), but you protocol does not need to be so generic. It can use application-level knowledge. For example, it will not be difficult for you server to determine that the corrupted data is the second operand of the requested operation and generate a corresponding message. Knowing the meaning of the possible responses to a message will help you handle corrupted responses. To handle loss and delay, your reliable protocol should use timeouts in a similar way as they are used at the Transport layer. To identify duplicates, you may or may not need to carry message sequence numbers – you may be able to utilize the application-level context of the message, but be careful to cover all possible situations. Testing Provide output showing the work of your protocol – the sequence of messages exchanged between the client and the server and capture screenshots of all significant cases. Documentation Provide separate class diagrams for the client and the server. List any design decisions you have made that you think may not be obvious from reading your programs. Describe in full the application-level protocol you are using, in words, in a state diagram, and with examples of sequences of actions. In the test report clearly state which functions of your program work and which do not. Development Requirements 1. Constraints. Coding must use C++ / CLI and generate executable programs. 2. Name constraints · for GUI applications: · Create a Visual Studio Solution folder, with a descriptive name for the assignment problem and Visual Studio version used e.g. Client_VS2019_Solution. Do not place the project and the solution in the same folder. · The start project name must be CppGUI_Project · The start form name must be Form1. Any additional forms must be named Form2, Form3, etc. · for console applications · Name the source file containing the entry point with a descriptive name, e.g. ConsoleClient.cpp. or Server.cpp. If your solution is implemented with several source files, place all source files in a folder named with the problem name, e.g. folder Server or Client. 1. Dependencies. You are encouraged to use global constants, but your program must limit the use of global variables to only the ones that are absolutely necessary for communication between forms. 2. Standards. Your programs must meet the programming standards attached below. Delivery Submit in the folder X:\Dropoff\CS\ganchevg\CS240\2020\Assignment3 in a subfolder named with your name, starting with your last name. Submit Task 1, Task 2 and Task 3 in separate folders. For GUI applications submit full Visual Studio 2019 solutions. For console solutions submit only the source files. Also submit in a subfolder Documentation: A. Grading sheet (supplied) with sections 1, 2 and 3 completed to show what you have done B. For each task · Brief description of the design decisions you have made and a description of the application-level protocol in words, in a state diagram, and with examples of sequences of actions. · Separate class diagrams for the client and the server showing the associations (relationships) between the classes of your program. · A test report showing: (a) Your assessment of which features of your implementation work correctly and which do not (b) Check-points, with a clearly indicated result (Y or N). (c) Screenshots illustrating the work of the protocol, explained with a description of the corresponding scenario (d) Include a brief analysis of any known errors which the program still produces, or state that the implementation is fully functional. Grading Schedule The assignment will be graded on an A to F scale of grades. Work which barely meets the minimum requirements and either has problems with usability or readability or does not meet the programming standards will be graded D- to C. Work which shows a useable solution with all the minimum requirements met and meets the programming standards will be graded C+ to B+. Work which in addition demonstrates exceptional robustness and reliability and has excellent documentation will be graded A- to A. Grading Sheet Name 1. Minimum Requirements (type your full name) (check the boxes below to claim credit for your work performed) · Task 1 · Task 2 · Task 3 3. Documentation submitted (check boxes of items attached) · Design Decisions, protocol · Class diagrams (client, server) · Test report · Source code 4. Non-functional requirements - screen layout - user interaction 5. Development Requirements - program organization - dependencies - data structures - method design - program layout - internal documentation