Real- time software /fall 99
     

    You must submit these laboratory exercises by the end of the study period one (every study period is 7 weeks). If you fail to submit a laboratory in time you get a new exercise to do, these laboratory exercises expire at the end of the period one. Being in time is checked from the date and time of your e-mail. To be late has also an effect to your grade. A past experience shows, that students easily underestimate the time needed to test a program to work and start the work too late, you are advised to participate labs and not to leave work to the latest moment.

    Copying from other students is strictly forbidden. Identical works are rejected, also the original one. So, do not give your code to other students. You must set all rights to access to your directory of labs only to the owner (rwx------; chmod 700 lab_dir). Of course, you can help other students to learn and you are even encouraged to do so, the method can't be to give a ready made code. Two programmers have not  identical solutions to any problem "big enough". If the solution is clearly the same, different variable names or comments are not enough to prove the work to be different from an other solution otherwise similar. In addition, the exam is based on the skills developed with these exercises, so, there is no point to copy anything.

    Introductory exercises (1) and (2) are based on the material  http://users.evitech.fi/~tk/rt_html/c.html, which is also explained during lecture hours.

    An exercise is completed only if:

    • Demonstrated to be working to the teacher during laboratory hours (questions asked)
    • An e-mail with the documentation,  the program source, the name of the author and the date of completion is sent to the address tk@evitech.fi (subject: lab name and number)
    The exercises written with red text are not mandatory to everybody to pass the course, but the grade is depending on your work done; more is better.

    First we take some basic disciplines as:

    • UNIX man- pages
    • compiling and linking a program using several separate source files
    • makefiles
    • libraries, header files
       
    (1) Compiling/header files/linking/separate modules
     
      Write a c- program which reads a count of integers to be read then set of integers, finds the biggest of these and outputs the result. Seeking of the biggest must be in a separate module (a different source file). Use a header file.
           Libraries
     
      Read the manual and info page of the ar- command.
      Put the subprogram object file of the previous exercise to your own library and test again.
      Study also dynamic libraries ( ld -b ..., dld.sl) make a simple documentation of Your experiment.
    (2) Makefiles
     
      (a) Read the manual page of make- command and use the info command (info make).
      (b) Create a makefile for the exercise (1). You must have a makefile in which You use a library and other without a library. Test again.

      (c) This was not all about the make. To learn more:

      •  Read the makefiles of my kernel (this helps also the real- time operating system course)
      •  Make a report explaining  how the make (of my kernel) works (at detailed level)
    (3) Modify and extend a simple IPC- example from course material (6.1.1).
     
      Write and test the following set of programs (simple client/server application) to get the basic idea of the so called inter process communication (IPC) of multitasking systems:
      • We have a server process and any number of clients running "simultaneously".
      • Clients send requests of a service to the server and get an answer to be displayed.
      • A client sends its identification and a file name to the server. The server sends back the file contents (use an ASCII file for testing). So the service provided by the server is like ftp get, but inside of one system.
      • You must give the question to be asked by a client as an command line argument to test the system properly (writing the question of every client using keyboard is too slow). You must create a command file for testing starting many clients "simultaneously" (in rapid sequence).

      • An example request in the command file script: ./client   file2.c, if the name of your client program is clientand the name of the file of some interest to client is file2.c
      • Use the system call mknod to create named pipes (FIFOs), in the example code pipes were created by an user command mknod. There are two manual pages for mknod. You can choose the manul page by the number:
              man 1 mknod or man 2 mknod, all system call are in the manual 2.
      • Unfortunately the Linux laboratory environment uses NFS filesystem. You must test your program on the system lelux.edu1.evitech.fi (you can't create FIFOs as usual with NFS):
          • Develop programs as usual on your Linux PC workstation
          • Take telnet connections from your own Linux PC for tests to lelux.ed u1.evitech.fi
          • Your C- code must create FIFOs in the /tmp directory  (NFS!)


      Make the previous exercise with the following additional features: A client must have a password for the file (each file has it own password and a client sends a string (in addition to the password) with the request. If the file in question contains the string the file is sent back, if not, answer is "No match", if the password is wrong the answer is "Wrong password". Passwords need not to be encrypted.
       

      Hints:

      • Clients can send a request packets to one named FIFO known to everybody and opened and created by the server.
      • The server opens a FIFO to every client using the name of the answer FIFO got from the client and sends the answer back.
      • You can give a name to the answer FIFO (you must have a unique name) based on clients process number (got using the system call getpid())and convert the number to a ASCII- filename.