----------------------- Lab #06 for CST8165 due December 6, 2006 (*** DUE DATE UPDATED ***) ----------------------- -Ian! D. Allen - idallen@idallen.ca Remember - knowing how to find out an answer is more important than memorizing the answer. Learn to fish! RTFM! (Read The Fine Manual) Global weight: 5% of your total mark this term. Due date: At the start of your lab period on Wednesday December 6. Interim submission: Wednesday November 29 You will submit whatever progress you have made on this assignment before midnight on Wednesday November 29. The on-line deliverables for this exercise are to be submitted on-line in the Linux Lab T127 using the "cstsubmit" method described in the exercise description, below. No paper; no email; no FTP. Late-submission date: I will accept without penalty exercises that are submitted late but before 10h00 (10am) Thursday December 7, 2006. After that late-submission date, the exercise is worth zero marks. Interim work must be submitted by midnight on November 29. Exercises submitted by the *due date* will be marked on-line and your marks will be sent to you by email after the late-submission date. Code submitted without your added useful comments (no matter what its source) will not be marked. Exercise Synopsis ----------------- Create/modify a small TCP/IP client or server (or both) of your choice. You may implement part of an existing RFC; or, you may use your own protocol (which you must then document). You may choose your own implementation language. Pick something doable and borrow code from the Internet (with credit) to help implement it. Document your program in README.txt, including a small User Manual or "man page" section on how to use it. Prepare a test plan. Test it. Submit the code and the results of the testing and a README.txt file that documents it all. All external documentation goes in README.txt. Yoy may work in pairs for this assignment. You may choose your implementation language(s). Suggestions: - basic text HTTP client - Ottawa weather client (HTTP client with post-processing) - FTP client - POP3/IMAP client (e.g. a "mail waiting" utility) - chat client/server (building on previous work) Where to work ------------- Submissions must run cleanly in the T127 Linux Lab, though you are free to develop and work on them anywhere you like. If you develop elsewhere, make sure the code works on the Linux Lab machines as well; that's where I test it! Code submitted without your added useful comments (no matter what its source) will not be marked. Code Quality and Portability ---------------------------- A. You must include useful comment blocks ahead of the code you write or modify. Code submitted without your added useful comments will not be marked. B. Marks are awarded for readability and elegance, not just correctness. If your code can't be read, you're useless in a team project. Coding ------ 1) For code you copy from the Internet, credit your sources. 2) If you obtain code from the Internet, keep a copy of the original files in a subdirectory "originals/" that you will submit along with your modified versions. (I want to see what modifications you made to the original code.) 3) Add comments to the any source code you start with, to bring it up to CST8165 standards. 4) In the README.txt file, under a heading "Team Work" at the start of the file, breifly document the names and work done by each member of the two-person team, if you work in a team. (You may work in a two-person team or alone.) 5) As usual, summarize your test plan in the README.txt file and cross-reference the README.txt file in your test plan. Include some form of test output (which may be in a separate file). Use automated testing, if possible, and supply your test script along with your project. The README.txt file is the principal repository for all your external documentation. Submission and Marking Scheme ----------------------------- Submission Standards (see earlier labs for details): 6) At the top of each and every submitted file, as comments, create an Exterior Assignment Submission label. This label identifies the file; it is not a substitute for proper documentation in the file. Your file will still need comments and function headers. 7) For material you copy from other sources, credit the author and source. If the comments in the source you copy are not sufficient, you must fix and add to them, just as if you wrote the code yourself. 8) Submit all your source files for marking as Exercise 06 using a *single* cstsubmit command line (always submit all files together): $ ~alleni/bin/cstsubmit 06 README.txt originals \ ...other files as needed... Submit all the files necessary to build, run, and test your small project. Do not submit object files or binary files. Submit a working Makefile if source needs to be compiled. 9) To be marked, the README.txt and originals/ paths must have the exact names given. Code submitted without your added useful comments (no matter what its source) will not be marked. 10) If you aren't sure if you've submitted all the necessary files for your project, change to a new empty directory and use cstsubmit to fetch back your submission, then expand it and test it. It should work. All files submitted must be named correctly and have assignment headers. Marking Scheme -------------- Project marks will be influenced based on attempted difficulty; however, a poorly documented and tested implementation of a cool program is usually worth less than a well-documented and tested implementation of a more modest program. (The company can assign someone to help work on a well-documented program. They have to throw out a poorly documented one.) Your test plan is key in demonstrating that your project works. All files submitted must be named correctly and have assignment headers. I'm deliberately leaving the scope of the assignment open. Show me what you learned in this course. Can you create, document, and test a TCP/IP client and/or server? You may write software from scratch; or, you may enhance already written software. You may write just a client, and test against netcat or an existing server; or, you may write just a server and test against netcat or an existing client. Or, you may write both ends. An "average" submission is a "C". Above-average submissions rate "B" or "A". Substantially below-average submissions rate "D" or perhaps "F".