The client program should be able to send the following type of requests to the server (obtaining data from the user/keyboard for each one):

First request: Include Client Number and Client Specific FIFO name for the server to reply to the client

Subsequent requests will be memory allocation or deallocation requests:

Memory request Include Client Number, MR (memory request) and Amount of memory requested (in bytes). Server should respond with a value indicating the memory address where the allocated memory for this client has been allocated. The client should save in a list or array the memory address and the size of this chunk of memory so that it can be deallocated (returned) later-see B).

Memory freed Include Client Number, MD (memory deallocation) and the memory address which is being returned/deallocated. Server responds with a simple acknowledge message indicating success or failure.

Client going away Include the Client Number to let the server know that this client is about to exit, so that the server can release all memory allocated to this client and close that clients FIFO. No response from the server should be expected.

Client should be doing these request in a loop where the user will choose which of A), B) or C) is wanted and collect appropriate information from the user to form and send the corresponding request. After every request, and reply from the server, the client should print to the screen a table that includes the starting address and size of each memory segment that has been allocated to this client.

Server:

The server should implement a First Fit Policy as described in the book (page 36) to allocate memory from an initial block of (fake) memory of a predetermined size. Server should be able to receive requests A), B) and C) as described above and handle them accordingly as follows:

Find the first block of memory big enough to satisfy the request, pick the block and allocate the memory for that client recording in a table similar to the one in page 38:

Memory location	Block size	Client/Job	Status
0	20K	2	BUSY
20K	80K		FREE

For instance, this is how the table would look like if the starting size was 100K and client 2 requested a block of size 20K (Note that a client may appear multiple times in the table after it has made several memory allocation request. The server can keep this table in a big array or preferable in a linked list. Server should respond to the client with a value indicating the memory address where the allocated memory for this client has been allocated.

Memory deallocations should be handled by the server taking care of updating the table/linked list correctly for each of the three cases described in pages 41-43. Server should respond to the client with a value indicating successful deallocation. (Maybe just return an integer 0 for success and -1 for failure, in the memory block being deallocated does not exist in the table).

When a client decides to quit, ALL entries previously allocated to that client should be freed and removed from the table/linked list accordingly.

After every requested handled by the server it should print the following to the screen:

Client Number Request Type Memory Block Size Starting Address

Followed by the new state of the table/linked list after the request has been processed and responded to.