NOTE: This assignment, like the other projects in this class, is due at a particular time, listed above. This means that if you are even a minute late, you lose 20%. If you are worried about potentially being late, turn in your project ahead of time. Do this by submitting it electronically before it is due and giving the hard copy to me during office hours or by sliding it under my office door before it is due. Do not send assignments to my personal email address. Do not leave hard copies in my departmental mail box or attempt to give them to departmental staff (who cannot and will not accept them).
In Projects 2 and 3, you took the first two steps toward the development of
a batch image watermarker by making use of existing software, such as a batch
downloader, an image compositing tool, and a file transfer tool, as components
of wm
and bwm
.
However, while bwm
had the functionality we were looking for,
the components weren't as well integrated as they could have been. This is
because while wm
and bwm
made use of other programs
to do some of the work, their communications with those programs was quite
limited. The only communication came through parameters passed to those
programs when they were called, the exit status codes generated by those
programs when they exited, and temporary files. This meant there was no direct
communication between these helper programs and wm
or
bwm
while they were actually running.
In this assignment, you will take a third step toward the development of an integrated batch water marking program by adding some inter-process communication (IPC). To keep the assignment simple, you will only add a tiny bit of IPC, and therefore a tiny bit of integration. This is only the third step, since we could do more work on integration and you are not assigned the job of creating a nice GUI front end for your water marking software. Still, it will let you gain experience with the basic mechanisms for dealing with inter-process communication.
You are to create a program called ibwm
(an acronym for
"integrated batch water marker"). When run, ibwm
will behave from
the user's perspective just as described for ibwm
in Project 3
with two exceptions.
ibwm
should overlap operations
to improve performance, as follows:
ibwm
is downloading multiple files, it will begin
watermarking each file as soon as that file is downloaded, rather than
waiting for all files to complete downloading. To achieve this, your code
should open a pipe to read the output of the download helper program you
are using (e.g., wget
) and parse that output as it is
generated. When the download helper program reports that it has downloaded
an image file, your code should immediately fork off a helper watermarking
program (e.g., composite
) to do the watermarking.ibwm
is watermarking multiple files, it will begin
uploading files as they are watermarked, rather than waiting for all files
to be watermarked before uploading begins. To achieve this, your code
should catch the SIGCHLD
signal from each watermarker helper
program (e.g., composite
) as it exits and add the proper
command to its stream of commands for the upload helper program (e.g.,
sftp
). Note, however, that (as mentioned in Project 3) your
program should wait one second between upload commands. This means that
even though your program should catch each SIGCHLD
signal as
it is generated, it should only tell the upload helper program about the
next file to upload after waiting at least one second after telling it
about the previous one.ibwm
should not create any
temporary files for communication between processes. In particular, many of
you have been creating a temporary file of commands to be executed by your
upload helper program (sftp
). While this was the recommended
way of communicating between your program and the upload helper program for
Projects 2 and 3, it will not be permitted for Project 4, now that you have
studied about IPC. Instead, for Project 4, your code must communicate with
the upload helper via a pipe. (Note that your code is not permitted to fork
off a separate child to handle each upload. Rather, your code must fork off
a single child to handle all uploads and must communicate with that child via
a pipe.)For implementing this functionality, you must use appropriate POSIX
system calls such as fork
and pipe
directly, rather
than higher level functions (such as popen
).
You will turn in both a hard copy and an electronic copy of your assignment. Electronic copies must be submitted to the appropriate drop box in D2L for the course. Do not send them to my email address.
Both the hard copy and the electronic copy will contain a cover sheet
documenting group membership and contributions (see below), all source code
you created for ibwm
, and a write-up of 1/2 to 1 page (roughly
80 characters per line, 50 lines per page) explaining the data structures and
algorithms used in your code. This page limitation does not include figures
used in your explanations, which are encouraged and may take up any amount of
space. (The explanations do not remove the requirement that your code be well
commented.)
The electronic copy will also contain an executable for ibwm
which should be called ibwm
.
Your source code must be written in C or C++ and must compile using gcc or
g++ on the CSN Linux computers. For creating new processes, changing the
executable, and checking on the progress of child processes, your code must use
fork
, exec
(that is, any of the exec family of system
calls), and wait
(or waitpid
), respectively. For the
creation of pipes, your code must use the pipe
system call. For
setting up your signal handler to catch signals, your code must use the
sigaction
system call, rather than the C signal
function call. Your code should be well structured and well commented. It
should conform to good coding standards (e.g., no memory leaks).
You may write your program from scratch or may start from programs for which the source code is freely available on the web or through other sources (such as friends or student organizations). If you do not start from scratch, you must give a complete and accurate accounting of where all of your code came from and indicate which parts are original or changed, and which you got from which other source. Failure to give credit where credit is due is academic fraud and will be dealt with accordingly.
As noted in the syllabus, you are required to work on this programming assignment in a group of at least two people. It is your responsibility to find other group members and work with them. The group should turn in only one (1) hard copy and one (1) electronic copy of the assignment. Both the electronic and hard copies should contain the names and student ID numbers of all group members. If your group composition changes during the course of working on this assignment (for example, a group of five splits into a group of two and a separate group of three), this must be clearly indicated on your cover sheet (see below), including the names and student ID numbers of everyone involved and details of when the change occurred and who accomplished what before and after the change.
Each group member is required to contribute equally to each project, as far as is possible. Your cover sheet must thoroughly document which group members were involved in each part of the project. For example, if you have three functions in your program and one function was written by group member one, the second was written by group member two, and the third was written jointly and equally by group members three and four, your cover sheet must clearly indicate this division of labor.
Note that all personally identifying information (names, student ID numbers, 4x4s, etc.) must only be included on the cover sheet and nowhere else in the project materials.