Assignment Phase 2
Background
This assignment aims to assess your C programming skills and forms the second phase of the development of a UNIX peer-to-peer file transfer application. The second phase of the assignment will build on from phase 1 to add network communications through sockets and the ability to handle multiple peers connecting simultaneously and will require asynchronous programming techniques.
You will be expected to submit not only the source code to your program but also a complete design for your program. The design can use pseudocode, flowcharts, functional decomposition, or another form of design and will be assessed on usefulness, correctness and coverage.
Objectives
Design and develop a program that does the following:
• Loads and uses a configuration file, called settings.conf;
o set (at minimum) the following internal variables
? Username
? Port
? IP address
? Logfile filename
o If the configuration file doesn’t exist, your program should create one with default values and log the event.
o If the configuration file is not readable, your program should continue with default settings and log an appropriate message.
o Any line beginning with a ‘#’ character should be ignored as a comment.
• Loads and uses a “sharing list” file that contains a list of records containing the following data:
o Filename of the file to be shared
o Full path of the file to be shared
o Sharing permissions for the file (Either shared with all or shared with individual users)
o If the sharing list file itself does not exist, it should be created.
o When the program starts it should check that each listed file exists and is readable. If it does not exist or is not readable, the file should be removed from the sharing list file.
• Maintains a sharing list and allows the user to add or remove files (with appropriate sharing permissions) to/from the sharing list
o Add/remove individual file
o Add/remove all files within a directory
• Loads and uses a “friends list” file that contains a list of known peer records containing the following data:
o IP address/hostname
o Port
o Username
o If the friends list file itself does not exist, it should be created
• Maintains a friends list and allows the user to add or remove friends to/from the friends list
• Allows the user to connect to a peer in the friends list and receive a listing of files shared by that peer (those that the user has permission to access)
• Allows the user to request a file to be downloaded from that peer.
o Downloaded files should be saved in a “downloads” folder.
• Allows multiple peers to connect and download files simultaneously from a single peer
• If the SIGQUIT (3) or SIGTERM (15) signals are received, your program should:
o Signal any children still active to terminate (if appropriate)
? If the children do not respond in a timely manner, your program should KILL (9) them
o Log an appropriate message to the log file
o Close all open files
• If the SIGHUP (1) signal is received (you will have to trap this signal) then
o Record the request in the log file
o open your programs configuration file
o read in the configuration file
o reset your programs parameters based on the configuration you read in
o open your log file
o record the final status of the SIGHUP process
o All current socket connections will need to be migrated over to any new network settings
• Contains a logging facility that logs at least the following information to a file:
o Program started (on IP:port)
o Program exited
o Sharing list created
o Friend list created
o File added to sharing list
o File removed from sharing list
o Friend added to friends list
o Friend removed from friends list
o Peer connected
o Peer disconnected
o File upload
o File download
The logger should run as a separate process and allow asynchronous requests to log information.
GNU Make should be used to build the application from source and your makefile should contain at least “make” and “make clean” build targets.
Functions should be loosely coupled and highly cohesive wherever possible. Your program source should be well structured and make use of multiple .c files and appropriate header files with clear separation of concerns.

Your submission should include, at minimum, the following files:
files.c and files.h
This should contain your main() program and code associated with your programs main logic such as reading and loading your configuration, maintaining file lists, taking input for instructions.
io.c and io.h
This should contain your code to do with input and output in general. This will be mainly File and screen i/o for phase one.
logger.c and logger.h
This should contain all your code associated with logging.
networking.c and networking.h
This should contain all your code associated with establishing connections to peers or sending data over a network.
settings.conf
makefile
Marking Guide:
Design Implementation
Use of make and multiple files 2
Use of friends list (loads, adds/removes and saves) 2 2
Socket functions (file uploads/downloads) 2 2
Code structure, make, comments and over all approach 2 2
Signals and concurrency 2 2
Program compiles and runs 2
Cool stuff (bonus) +2
Sub-Total 8 12
Total 20
So you think you’re done:
o Does your program compile and run?
o Is your program in multiple files and is then linked together?
o Using #include to copy .c files into your main program file is NOT appropriate!
o Does your program load and use a friends list save file?
o Can you edit the friends list? (Add/remove/view file and user entries)
o Does your program deal with bad input?
o Can a peer select a file from your sharing list and download it?
o Can multiple instances of your program download files from you simultaneously?
o Can you select a file from a peer’s sharing list and download it?
o Do you use fgets(), fputs() and/or fprintf() and avoid scanf() and printf()?
o Does your program create a logfile if one doesn’t exist?
o Does your logger actually record the required events in the logfile?
o Does your logger run in a separate process?
o Do you handle the SIGQUIT, SIGTERM and SIGHUP signals?
o Does each of your functions do only one thing?
These are some of the things we will be looking for when we mark your assignment. These are testing guidelines and do not entail all of the testing you will need to do to ensure you meet all of the assignment requirements. You should look to make your program as robust as possible.