CS111 - Project 1A: I/O and IPC

INTRODUCTION:

In this project, you will build a multi-process telnet-like client and server. Part A of the project (this part!) can be broken up into two major steps:

You will be extending the same code in Project 1B, so make sure it’s readable and easy to modify.

RELATION TO READING AND LECTURES:

This lab will build on the process and exception discussions in lecture 3, but it is really about researching and exploiting APIs.

PROJECT OBJECTIVES:

DELIVERABLES:

A single tarball (.tar.gz) containing:

PROJECT DESCRIPTION:

You will write a program that compiles to an executable named lab1a, and will accept the command line argument --shell (explained below).

  1. Study the following manual sections:
  1. Character-at-a-time, full duplex terminal I/O: write a program to
  1. Passing input and output between two processes: extend part 1 to support a --shell argument to pass input/output between the terminal and a shell:
  1. another thread should read input from the shell pipe and write it to stdout.
  2. if you’d like, you can do this with only one extra thread, as the parent process is itself a thread.

SUBMISSION:

Project 1A will be due on Wednesday, October 5.

Your tarball should have a name of the form lab1a-studentID.tar.gz and should be submitted via CCLE.

We will test it on a SEASnet GNU/Linux server running RHEL 7 (this is on lnxsrv09). You would be well advised to test your submission on that platform before submitting it.

A NOTE ON CR, LF, AND EOF:

Long ago, when interaction was through mechanical teletypes, these ASCII codes had the following meanings:

0x0D        carriage return, meant move the printing head back to the left edge of the paper.

0x0A        line feed, meant move the paper upwards one line

0x04        end of file, meant there is no more input.

So every line of text ended with <cr><lf> or 0x0D 0x0A. This is still the case in Windows.

Other people felt it was archaic foolishness to require two characters to indicate the end of line, and suggested that <lf> 0x0A (renamed newline) should be all that was required.  This is how files are represented in UNIX descendants.  But when output is sent to a virtual terminal, the newline is still translated into the two distinct motion characters <cr> and <lf>.

DOS systems used to actually put a 0x18 (^Z) as the last character of a file to indicate END OF FILE, while most other operating systems simply ended the data (subsequent reads return nothing).

RUBRIC:

Value        Feature

        Packaging and build (15%)

5%        untars expected contents

5%        clean build w/default action (no warnings)

3%        Makefile has clean and dist targets

2%        reasonableness of README contents

        

        Basic functionality (25%)

10%        Correctly changes console to char-at-a-time, no-echo mode

10%        Keyboard input is written to the console one character at a time

5%        Handles long inputs

        With the --shell option (45%)

10%        forks a process for the shell

10%        in one thread (may be the parent process), correctly pass keyboard input to stdout and to shell

10%        in a separate thread, read input from shell pipe and echoes to stdout

3%        On ^D: sends SIGHUP to shell, RC = 0

3%        On ^C: sends SIGINT to shell

3%        SIGPIPE from shell to parent, RC = 1

3%        EOF from shell: exit, RC = 1

3%        Report shell’s exit status on exit

        Miscellaneous (15%)

5%        Correctly interprets <lf> and <cr>

10%        Restores terminal modes on program exit