Project #3 - Server Process Pools

Version 1.0,
Due Date: 12:00 am, Sunday, Wk7

Purpose:

Developing software consisting of multiple packages requires frequent testing. If the software has complex features, we want to build it incrementally. First design and implement a very basic core with a small number of packages, then add features one-at-a-time by adding new packages, or adding a few lines of code to an existing package. Each time we add new functionality, we build and test. That way, if additions break existing code, we know where to look, e.g., in the newly added few lines of code. A test harness allows us to use that incremental process efficiently.
A test harness should allow us to define and aggregate many small tests, each of which run with exception handling and results logging. Our goal is to do that without littering our code with many try-catch blocks and many logging statements. The technique we use to do that is to define, in the test harness, an execution function that accepts a callable test object2 - function pointer, functor, or lambda - and invokes the object within the scope of a try block. A catch clause displays exceptions and returns false to indicate test failure. Otherwise the executor returns the test predicate returned by the test object, e.g., true or false for pass or fail.
The test executor also provides results logging with predefined messages. Your test harness should define several levels of loggin, e.g., just pass or fail, or more detailed, test-specific messages, or very detailed debugging messages, which display a time-date stamp and the values of key test-defined variables.
The test harness provides a mechanism to link any number of tests into a test sequence. Typically, during development, we keep adding tests for each new feature, and can rerun tests just for that feature, or all the tests of all the features, to insure that the new addition didn't break existing functionality.
In this project you will develop a communication channel, based on code you will find in the Repository. You will then develop a Process Pool mechanism that runs each TestRequest (see below) in its own process. These test processes are created once, and reused to process subsequent test requests. The communication channel is used to communicate between child tester processes and the mother TestHarness process, by passing messages.

Requirements:

Your Remote Code Repository Prototypes Project:
  1. Shall be prepared using the latest version of Visual Studio, and written in the standard C++ programming language, using the standard C++ libraries.
  2. Shall use Visual Studio, Community Edition available at no cost.
  3. Shall implement a message-passing communication channel using Sockets, based on the Channel prototype found in the Repository.
  4. Shall define a Message class that provides:
    • Source and Destination addresses
    • Message type
    • Author
    • Time-Date
    • String body:
      Expected to hold an XML string supplying information needed to execute a specific request.
  5. Shall define methods for sending messages and for uploading files.
  6. Each communication EndPoint1 shall provide both a Sender and a Receiver, wrapped in a Comm class2.
  7. Shall provide a TestHarness Package that creates, at startup, a specified number of child processes. The child processes post Ready messages to the TestHarness on startup.
  8. Shall provide a Client package that posts one or more TestRequest messages to the TestHarness. You will find it convenient to have the TestHarness provide a BlockingQueue for TestRequests and a BlockingQueue for Ready messages. It uses a child thread to extract messages from its Comm using getMessage(), and enqueue the message in the appropriate queue. The main TestHarness thread dequeues these and sends the test request to the child tester that sent the Ready message3.
  9. Shall program the Executive to provide several TestRequests in quick succession to demonstrate that the process pool executes TestRequests concurrently and that each will, on completion, post a Ready status message to the TestHarness and await the next TestRequest message.
  10. Shall log test results, demonstrating that the requirements, above, are met.
  1. A communication EndPoint is a machine address concatenated with a port number, separated by a colon character.
  2. You will find that the Comm helper code provides almost all of that.
  3. Remember that messages have "to" and "from" EndPoint members.

What you need to know:

In order to successfully meet these requirements you will need to know:
  1. How the helper communication code works.
  2. How to use the BlockingQueue class.
  3. How to start Windows Processes