CMSC 332: Computer Networks
Spring 2016
Course Syllabus
- Instructor: Doug Szajda (my_first_initial_concatenated_with_my_last_name 'at' richmond.edu),
219 Jepson Hall, (804)-287-6671 (campus ext. 6671).
- Meeting Times:
- Lecture: MW 1:30 - 2:45 p.m., Jepson 231.
- Lab: F 1:30 - 2:20 p.m., Jepson G22.
- Required Texts:
- Computer Networking (7th Edition), by James F. Kurose and Keith W. Ross, Pearson Addison-Wesley, 2010
- TCP/IP Sockets in C: A Practical Guide for Programmers (2nd Edition) by Michael J. Donahoo and Kenneth L. Calvert,
Morgan-Kaufmann, 2009.
- Recommended Text:
- C Programming: A Modern Approach (2nd Edition), by K.N. King, Norton, 2008.
- Office Hours: TBD. If you need to see me, please talk to me after class or email me.
You are also welcome to drop by my office at any time, but
be aware that there will be occasions on which I will be unable to see
students (or will be away from my office). Also, though I usually keep
my office door open during office hours, at other times I may
keep my door closed for either noise or climate control purposes. You
should be sure to knock before concluding that I am not in my office!
Skype: Some students seem reluctant to use skype. I understand that, as nothing works
as well for discussing problems as in-person conversation. But because of meeting
schedules, appointments, etc, I will sometimes need to work from home. If this is the
case (e.g., I need to be home some afternoon, and you need help) you are welcome to
email me to set up a skype time. Please understand that I do not mind this, and it is
not at all an imposition. It is a method by which I can help you with your networks-related
problems even if I am not in my office when you need help.
- Course Summary: Communications networks are
fundamental to our everyday lives. Whether for enabling global scale
commerce or connecting long lost friends, these systems have created
an unparalleled age of information. Accordingly, knowledge of such
systems is critical for all scientists and engineers. This course
provides an overview of networking technologies. Students
satisfactorily completing this course will gain the skills necessary
to analyze and design networking systems and protocols. The course
will begin with the application layer, looking at design patterns
present in common application layer protocols. We then move down the
network stack, considering topics such as reliable transmission and
congestion control at the transport layer, routing at the network
layer, and multiple access protocols at the link layer. After this
discussion, the latter portion of the course will include
wireless/mobile networks and devices, queuing fundamentals, security,
and network management.
- Pre-requisites: The pre-requisite for this
course is CMSC 301 (Computer Architecture) or permission of the instructor.
- Class Participation: To do well in this course, students must
take active and regular roles in discussion and demonstrate
comprehension of the reading and lecture themes. Students are required
to do the assigned reading before class. I will be closely
monitoring this.
- Attendance Policy: Regular attendance for the entire class time is
expected! I don't take attendance, so if you're missing so many classes that I notice, you've missed too many. If you should miss a class due to illness,
you are responsible for obtaining class notes! (Under
no circumstances will I give you a private encore of a missed lecture!) Note that
not all class discussions will be covered in the text, so it behooves you to attend!
- Grades:
| Grade Component |
Date |
Percent of Grade |
| Homework |
N/A |
10% |
| Programming Projects |
N/A |
30% |
| First Midterm |
Distributed Monday, February 26 |
15% |
| Second Midterm |
Distributed Monday, April 9 |
15% |
| Final Exam |
Monday, April 25; 2:00 - 5:00 pm |
25% |
| Participation |
N/A |
5% |
- Exams: The course will include two midterms and one final exam. All exams
will be take-home, closed-book, closed-note, closed-Internet. Students
are responsible for material covered both in the text AND
lectures.
- Homework There will be four graded homework assignments in this course.
These problems should be considered essential as partial preparation for the exams.
- Programming Projects: This course requires the completion of
four programming projects.
Projects must be written in C/C++ and submitted as a single tar file (note, ZIP files are
not allowed -- this is networks!) as an attachment
to an email sent to an address that will deposit your submission in a Box folder. The list
of emails required for the assignments are contained in a file on the content page of the course
blackboard page. Submissions must be received by 5:00 pm on the due date, unless
another time is explicitly stated in the assignment.
See the lateness policy below.
Note that this is a systems course - successfully completing coding
assignments is a necessary condition for earning a desirable grade.
Moreover, the projects are an
essential part of the learning process. For this reason, if a
student is missing even a single project
at the end of the course, he or she will receive a grade
of `F' for the course!
- My "Managerial" Philosophy:
I treat you like adults and expect you to act like adults.
For the 1% of you that may need a little clarification, here are some (though not all) of the notions that this entails:
- You begin assigned work in a timely manner (this includes reading).
- You complete assigned work on time (this includes reading).
- You complete assigned work and hand it in on time.
- If an emergency arises (as they sometimes do) that precludes handing in work or taking an exam, you contact me before the work (or exam) is due.
- You accept responsibility for your actions (and/or, as the case may be, your inactions).
- Lateness Policy:
Assignments and project milestones are
assessed a 15% per-day late penalty, with a maximum of 4 days. Unless
the problem is apocalyptic, don't give me excuses. Students with
legitimate reasons who contact the professor before the deadline may
apply for an extension.
- My ``exam discussion policy": Once a student has begun an exam,
I will answer (for that student) only those questions that concern clarification of the intent of a problem. That is,
I will not answer questions that seek to determine whether the problem was done correctly, or whether a particular approach is
wise (or unwise).
- The Other Student Criteria: When grading tests and
homework, I use the Other Student Criteria
(OSC). All solutions must meet this. The Other Student Criteria
states that a solution should provide enough written explanation
so that another student in the class (who could not complete the
assignment) could read the submitted material and, without
asking questions, understand a correct answer.
- Programming Assignments: Unlike some of the
lower level CS courses, in this course (and any other senior level course)
a program must
both compile without errors (as defined below) and
run according to specification to receive any credit!
There are a number of
other factors that may influence the grade that a program receives. Here are
some of them:
- Is the program "user-friendly"? That is, does the user have
to guess at how to use the program, or does the program somehow
provide this information to the user?
- Is the code readable? (One letter variable names, other than for loop indices,
are strictly prohibited!)
- Is the code well documented? Every program assignment grade will
have a significant documentation component. No one should have to dig through
poorly documented code (try it some time)!
- Is the code "well-structured"?
- Is the code robust? For example, how does the program
react if the user supplies the wrong number of command line arguments?
- How well has your code been debugged? Specifically, I will be collecting debugging information from
you as part of the material submitted with programming projects.
- You should consider me a client who is purchasing your code. As
the developer, it is your responsibility to ensure that I receive the latest
working version of
your
source code and
that
it compiles
correctly
on the CS Department Linux cluster.
If you happen to submit an old version of your code by accident, or
you submit binaries instead of source code, then I'm not going to be a happy customer.
- In line with the previous item, the version of the code you submit to me should have all debugging output
removed. This does not mean that you have to remove the debugging code from
the source. It does mean that when the code runs, I should not be getting
debugging output by default.
- The Programming Environment: We will be coding in UNIX based
environments and
using the command line and whatever editor you prefer.
All programming assignments must satisfy and/or include the following:
- They must be implemented in C or C++.
- They must compile without warnings using the installed GNU C or C++ compiler, with
the -Wall option, on the department Linux cluster.
I mention this because C is, well, not always portable (but you knew that), and so it
is possible (and in fact likely for some of these projects) that
network code that compiles and runs correctly on one platform will perform differently on another.
- Every project must include a thorough (though concise) report describing
the final testing you performed in order to convince yourself that the
program meets all project specifications.
- All files included in the project (i.e. README file, C or C++ source, etc) must be submitted in a single
tar file. You should be sure to include in your submission any
supplemental source code or files I may have supplied for the project!
The bottom line here is that I should be able to untar your submission, compile your source, and execute your code in three easy steps.
- Programming Help: I am happy to discuss programming and debugging techniques, as well as the
semantics of particular functions calls. I am happy to direct you to appropriate packages. And I will
at times provide you with "shell code". With regards to programming, I am in general happy to help you in whatever way
is necessary. I will not, however, debug your code for you! If you describe your programming issue
with me, I will be happy to suggest potentially useful debugging strategies.
But debugging is an important part (and in fact the majority part for these projects)
of the programming process. As such, you
need to be comfortable with doing it on your own!
- A word of warning: I mentioned above that debugging is an essential part of the programming
process. For the project in this course, you might end up spending four or five times more
effort in debugging your code than in writing it! Several years ago I spent one afternoon
coding one of these assignments, and four days debugging it (it worked fine on one of my laptops,
and crashed with a segmentation fault on another). This is the nature of the network programming
beast. You need to take this into account when planning the time you intend to spend on a programming
project.
- Collaborating on homework/programming assignments: Programming projects
and homework may be discussed with others subject to the
``Empty Hands'' policy ---
you may freely discuss ideas and approaches with other students
subject to the restriction that each student must leave the discussion
without any written or otherwise recorded
material. In your homework write-up or source code, you must also
document any person or source that you consulted for that project.
Failure to comply with this policy will be treated as an Honor
Code violation.
One final note: some of the programming assignments
for this semester may have been assigned in previous semesters.
While you may consult previous class members concerning projects,
you are not permitted, under any circumstances, to receive
or view either hard copies or electronic copies of all or parts
of their project submissions! You can use your friends to
get help, but they should not be providing you with their code
(just as in an English class, you might discuss the works of Dickens
with a friend, but should not use the paper that they submitted
as the basis for your own submission).
- Note: Many of the handouts, presentation slides, and projects used in this course use material borrowed from
colleagues in the networks and security fields. I am particularly grateful to Patrick Traynor for generously allowing me
the use of his material as the basis for my material (including, in some cases, simply using his material word-for-word).
|
|
|