Computer Science and Engineering

CSE 222 - Systems Programming

Home     Syllabus     Assignments     Exams

Lectures     Examples     Links



Assignments

Index Links:




Homework

  1. Due no later than 2009-04-01 0800: Flowcharts of Coordinated Processes

    1. Draw a flowchart of the "Rock Paper Scissors" implementation for MP4 indicating the communications between the parts of the processes.
    2. Use the basic flowchart symbols given on the board in class.
    3. Include a key of the symbols used and explaining their meaning.
    4. Turn in the hardcopy at the start of class on 2009-04-01.

    Hint: Keep the flowcharts at as high a level of abstraction as possible that still allows showing the separate communications and decisions based on communicated data.

  2. Due no later than 2009-04-15 0800: Flow diagrams of Coordinated Processes

    1. Draw a flow diagram (as defined in class) of a "Rock Paper Scissors" implementation using parent/child processes and shared memory/signals communications.
    2. Use the basic flow diagram concepts presented on the board in class on 2009-04-08.
    3. Include a key of the symbols used and explaining their meaning.
    4. Turn in the hardcopy at the start of class on 2009-04-15.

    Hint: The flow diagrams indicate the subset of system calls of interest, and indicate the flow (order) of execution and communications.




Mini Projects

Turn-in instructions:

Electronically turn in a single tarred and gzipped package (see the tar/gzip instructions. Do NOT use rar, zip, slt, or a variety of others, as ther are more packages every day, and there are many old compression packages, and standardization is essential to smooth running projects. Your turn-in package should include:

Send the turn-in package as a mail attachment to jholten@nmt.edu as specified in the syllabus project turn-in instructions.

Grades will be based on the clarity and usefulness of the two papers, as well as the readability of the source code and success of the student (and their program) in satisfying the posted requirements. The program success will be judged by an attempt to run it via the assignment instructions and following the written instructions on its use. Points will be taken off if the package is not tarred and gzipped as requested, or if the package is missing essential files or file contents.

  1. Due no later than 2009-01-26 0800:
    This mini-project is called mp1.

    Goals:

    1. Demonstrate that you can access the TCC machines, build the deliverable package, and mail the deliverable package as your turn-in.

    2. Demonstrate that you can obtain man pages, particularly ones that are essential to the next steps in this class.

    In this assignment's description code samples "ID" is intended to be replaced by your TCC login ID.

    Do the following:

    1. Log into the TCC machine "pi.nmt.edu". If you are doing this as a remote access you may use

         ssh ID@pi.nmt.edu
      
      from any of a variety of operating systems, sometimes using packages as indicated on the links page in the Support Needs section .

    2. Perform the following command sequence on the TCC machine:

         mkdir ID_mp1
         cd ID_mp1
      
         whoami > mp1_info.txt
         date >> mp1_info.txt
         pwd >> mp1_info.txt
         uname -a >> mp1_info.txt
      
         man -t man > man.ps
         man -t errno > errno.ps
         man -t strerror > strerror.ps
         man -t 2 time > time_2.ps
      
         cd ..
         tar -cvzf ID_mp1.tgz ID_mp1
      

      At this point you have your "turn-in" package in ID_mp1.tgz so you may use scp from your remote system to copy down the file and attach it to your turn-in mail to me.

    3. You may get help from fellow students and other sources, but turn in only your own work.

    4. Due no later than 2009-01-28 0800:
      This mini-project is called mp2.

      Goals:

      1. Demonstrate that you can use the man pages to determine how to use the errno and strerror() UNIX error system features and call the file stream I/O system functions fopen(), fgets(), and fclose(), identifying which errno values may be associated with each call.

      2. Demonstrate that you can check for a failure on each system call and detect the error conditions for that call, putting out an error message for each appropriate error condition which includes the strerror() string that UNIX associates with the relevant errno that may be returned.

      3. Demonstrate that you can get measure total execution times, use repetitions to estimate single execution times, access files, and check all relevant error conditions for each system call.

      There are a number of files on pi.nmt.edu in the directory ~jholten/cs222_files/ that are to be used for this assignment. These are the parts to this assignment:

      1. Write the code to perform an fopen(), an fgets(), and an fclose() on a single file, checking all the errno values that may occur if the operation fails. If an error occurs print out a relevant error message, including the UNIX strerror() string for the errno for the failure.

      2. Loop over the 100 mp2_file_nn files (where nn is in [0, 99]), performing an fopen(), an fgets(), and an fclose() for each file. Get the total execution time for accessing the 100 files. Also calculate the average time per file. Write out the total time in seconds, and the estimated time per file in milliseconds.

      3. Loop over just the first (mp2_file_0) file performing the fopen(), fgets(), and fclose() sequence on the file 100 times. Get the total execution time of performing the 100 repetitions. Also calculate the average time per access. Write out the total time in seconds, and the estimated time per access in milliseconds.

      4. Perform the fopen(), fgets(), and the fclose() on the MP_Problem file, printing an appropriate error message if any fail. If one fails just continue on to perform the next system call after putting out the error message.

      For this project you should turn in the full complement of files, the user guide (UG), the journal, the source code you generated, and the results data file you wrote.

      You may get help from fellow students and other sources, but turn in only your own work.

    5. Due no later than 2009-02-11 0800:
      This mini-project is called mp3.

      Goals:

      1. Write programs to play "rock, paper, scissors". This will include a referee program and a player program which may have multiple instances activated.

      2. Use pipes to communicate between the parent process and each child process. The communications will be bidirectional.

      3. The referee process will spawn two player processes, then coordinate them by activating 10 consecutive rounds of "rock, paper, scissors", gettin back the response from each player process, and report the round by printing the reply of each player and indicating which is the winner into a results file. Each player process, when told to begin a round, will randomly pick rock, paper, or scissors, and reply to the referee process their choice.

      Hints:

      1. The parent process should fork() to generate the two child processes.

      2. Before the parent process fork()s to generate a child processes it should create two pipes, one to go TO the child and one to come FROM the child process.

      3. After the parent process fork()s but in the CHILD branch before it does the exec() to replace the parent program in the child process with the child program it should prepare the pipes for the child process:

        1. Close the write end [1] of the pipe to the child process (the child will only read on it)

        2. Close the read end [0] of the pipe from the child process (the child will only write on it)

      4. After the parent process fork()s but in the PARENT branch it should prepare the pipes for the parent process:

        1. Close the read end [0] of the pipe to the child process (the parent will only write on it)

        2. Close the write end [1] of the pipe from the child process (the parent will only read on it)

      5. After a child process has been activated the parent process should have two file descriptors for communicating with that child process, one for reading, and one for writing.

        After the child process has been activated the child process should have two file descriptors for communicating with its parent process, one for reading, and one for writing.

      6. After both child processes have been activated the parent process should have 4 file descriptors just for communicating with the child processes. The parent process should set up a select() and wait for the child processes to announce that they are up and waiting.

        After the child processes have both announced that they are up and ready the parent process should go into an RPS loop to handle the 10 iterations. In that loop the parent process should:

        1. Tell the child processes to "go".

        2. Wait on the select() for the child process answers, reading them in as the child processes respond.

        3. After both child process responses are received determine whether it is a tie, or if not, which child won, printing the responses and the winner/tie information.

      For this project you should turn in the full complement of files, the user guide (UG), the journal, the source code you generated for each program, and the results data file you wrote.

      You may get help from fellow students and other sources, but turn in only your own work.

    6. Due no later than 2009-04-06 0800:
      This mini-project is called mp4.

      Goals:

      1. Write programs to play "rock, paper, scissors" (RPS). This will include a referee program and a player program which will have two instances activated.

      2. Use TCP/IP sockets to communicate between the referee process and each player process. The communications will be bidirectional. The players must be able to run on separate machines.

      3. The referee process will start and wait for two player processes to connect, then coordinate them by activating 10 consecutive rounds of "rock, paper, scissors", getting back the response from each player process, and report the round by printing the reply of each player and indicating which is the winner into a results file. Each player process, when told to begin a round, will randomly pick rock, paper, or scissors, and reply to the referee process their choice. When told to stop the player processes with send back a stop message and terminate.

      Hints:

      1. The referee process should be started on one system, then the player processes may be started on one or two other systems.

      2. When the referee process comes up it should create its socket, bind it to a socket number (generally over 5000 is good), then loop while listening on the socket for the two child processes. As the child processes try to connect it should detect them and accept the connections, then wait for a "ready" message from the player.

      3. Each child process, as it comes up, should create a socket, then try to connect to the referee process's socket. You must provide the player processes with the referee's IP address and the socket port number you have used.

      4. After the connections have been made the processes will communicate using "select" as in mp3. It may also be used to coordinate the "listen/accept" cycle in the referee process.

      5. After a player process has been activated the referee process should have a single file descriptor for communicating with the player process, for both reading and writing. This comes from the "accept" call in the referee.

        After the player process has been activated the player process should have a single file descriptor for communicating with its referee process, for both reading and writing. This file descriptor comes from the "connect" call in the player process.

      6. After both player processes have been activated the referee process should have 2 file descriptors, one for communicating with each of the player processes. The referee process should set up a select() and wait for the player processes to announce that they are up and waiting.

        After the player processes have both announced that they are up and ready the referee process should go into an RPS loop to handle the 10 iterations. In that loop the referee process should:

        1. Tell the player processes to "go".

        2. Wait on the select() for the player process answers, reading them in as the player processes respond.

        3. After both player process responses are received determine whether it is a tie, or if not, which player won, printing the responses and the winner/tie information.

      For this project you should turn in the full complement of files, the user guide (UG), the journal, the source code you generated for each program, and the results data file you wrote.

      You may get help from fellow students and other sources, but turn in only your own work.

    7. Due no later than 2009-04-27 0800:
      This mini-project is called mp5.

      Goals:

      1. Write programs to play "rock, paper, scissors" (RPS). This will include a referee program and a player program which will have two instances activated.

      2. Use shared memory to communicate between the referee process and each player process. The communications will be bidirectional. The messages passed in shared memory should be "announced" using SIGUSR1 to the receiveing process, which should be hanging on a select() call.

      3. The referee process will spawn two player processes, then coordinate them by activating 10 consecutive rounds of "rock, paper, scissors", gettin back the response from each player process, and report the round by printing the reply of each player and indicating which is the winner into a results file. Each player process, when told to begin a round, will randomly pick rock, paper, or scissors, and reply to the referee process with their choice.

      For this project you should turn in the full complement of files, the user guide (UG), the journal, the source code you generated for each program, and the results data file you wrote.

      You may get help from fellow students and other sources, but turn in only your own work.



Home     Syllabus     Assignments     Exams

Lectures     Examples     Links

 
  Site Map  |  Contact Us