Labs

The lab questions below are optional. If you solve them I would be happy to check them out and give you feedback. If you choose not to bother with them no worries, similar concepts will appear in the assignments.

Week 1: Concurrent programming

There exists a Unix command called file which tests each of its arguments (which must be file names) in an attempt to classify them. It then prints a short description of all the arguments. For instance, the command file applied to a C++ source file foo.cc will print:

    foo.cc: ASCII C program text

The following asks you to write a wrapper for the Unix command file, as follows: Your program reads from the standard input a number of file names, one per line. For each input, the program invokes the command file and prints to the standard output the result. The program terminates when it reads an empty string.

Create two versions of the program, one what waits for a file command to complete before issuing the next command, and another that does not wait (instead, the command file will be called on the file name given by the just read line before processing the remainder of the input). No matter the version there must be no input prompt.

General note on testing

If you attempt to run the program interactively (i.e., with the names of the file typed at the keyboard) you are likely to run into problems because of the multiple processes that run concurrently. However, Unix offers a way of ``redirecting'' the input and/or output of a program, and you can take advantage of this feature.

Suppose that you have a program called foo that reads/writes from/to the standard input/output (i.e., by using cin and cout). Then, you could type the following command:

    ./foo < some_file

The effect is that foo receives the content of some_file as input (including newlines), just as if someone would have typed this content while foo runs.

The output can also be redirected to a file. The following command puts the output of foo into the file results instead of printing it to the terminal:

    ./foo > results

Of course, the two redirections can be combined, e.g.,

    ./foo < some_file > results

Finally, the output of one program can be fed as input to another program. For example, in the following command the input of foo is the output of the command ls:

    ls | foo

In terms of your program, I recommend to test it by redirecting the input (and possibly the output). For instance, you could perform the following tests (I assume that the executable is called files):

• Use as input the result of a ls command, e.g.,

      ls -a | ./files
  

  This will (hopefully) call file on all the files contained in the current directory. Then,

• Prepare an input file (let's call it input) and do

      ./files < input
  

• You could of course redirect the output of both the above commands, like this:

       ls -a | ./files > results1
      ./files < input > results2
  

Week 1: File I/O

• Modify both variants of the program you wrote for the previous question so that they now put the result of the file invocations in a file whose name is given as command line argment. Use for this purpose POSIX file I/O calls.
• Replace the call to file to a more verbose call such as cat. Test both variants of your program under suitable input re-direction. Do you note any difference in the output of these two variants? Why (not)?

Week 2: Assignment 1

Week 2: TCP Clients

1. Take a look at the sample client code from the previous section (including the TCP utilities from the tcp-utils module). Make sure you understand what happens in there (and ask me if you don't). Build the code and play with it. What are the (major) differences between this client and the telnet client?

   In answering this question you may want to try various well known services such as SMTP (port 25) and HTTP (port 80). You will need to find the application protocols for these services by yourself.

2. Extend the sample code so that its functionality is modified as follows: The client receives as command line arguments one host name h, one port p, and the name of a (possibly nonexistent) file f. It then connects to h on port p and repeatedly performs the following:
   1. If the server shuts down the connection, prints a message in this respect and returns.
   2. Prompts for and reads a string from the standard input.
   3. If the read string does not start with a colon (i.e. ``:''), then:
      1. Send the string to the server, and waits for the answer.
      2. Once the answer has been received,
         1. Prints all the lines of the answer to the standard output, prefixed by <--, and
         2. Writes the answer to the file f. Each line in the answer must be prefixed by the name of the host the client runs on and the current date and time, everything separated by colons (``:''), e.g.,

            j118-1.ubihsops.ca:Thu Jan 25 13:36:44 2007:503 5.0.0 Polite people say HELO first
            

            The answer given by the server could be on more than one line, and there is no character that signals the end of the answer. You should thus read the answer until no data is available (within a reasonable time).
   4. If the read string starts with a colon, then:
      1. If the string starts with ``:q'' then partially shuts down the connection for writing, awaits the partial shutdown from the server, and exits.
      2. Otherwise, ignores the current input.
   5. Repeats from Step 1.

   Writing to file f should not destroy anything that is already there. If f does not exists, it should be created anew. Any error condition encountered during the processing must generate a suitable error message.

Week 3: TCP Clients (cont'd)

Week 3: A Simple Shell Server

Welcome to the wonderful world of servers. We shall now build sort of a remote shell server that will accept commands from clients and will execute them locally. All the incoming requests (except for the particular request CPRINT, detailed below) are considered normal shell commands. The server then attempts to run the given command locally, and replies upon completion with one ``status line'' that has the form

status code message

where

• status is one of OK (signifying that the command completed successfully), FAIL (meaning that the command could not be executed), and ERR (meaning that the command terminated prematurely because of an error condition).
• code is an error code, with the following meaning:

  Response	Meaning of code
  OK	always 0 (zero)
  ERR	the (non-null) exit status of the executed command
  FAIL	the server-side error code (errno) that describes the cause of the failure

• message is a plain text message intended for human consumption; in a FAIL message it would be nice for this field to contain the readable description of the error code.

Commands may print things to the standard error and output streams when running. Such an output is not sent back to the client by default. Instead, the stuff printed by the most recently executed command is remembered by the server and is sent to the client only upon request. A client can ask for the output of the most recent command by issuing the following request:

CPRINT

Upon receipt of such a request, the server sends to the client the (possibly empty) output of the most recently executed shell command, followed by a ``status line'' as described before. A FAIL such a line is emitted when an internal server error prevented the output to be produced, and an ERR line is sent only when no command has been issued in the current session (and thus there is nothing to print); in the latter case, the error code shall be set to EIO (input/output error).

Your server must be concurent. You are further required to use single-threaded processes for this assignment.

Week 3: A Simple Shell Server (cont'd)