No Title

CPS 214 Computer Networks and Distributed SystemsDuke University, Fall 1996Prof. Thomas NartenE-mail: narten@raleigh.ibm.com
Office: LSRC D105Phone: 254-7798

Times and Places

Classes meet 5:30-6:45 Mondays and Wednesdays in room LSRC-D106 (Levine Science Research Center). Since I come to Duke regularly only to teach this course, I don't have set office hours. I will, however, generally be available immediately after class. For other times, please make an appointment. I can be reached most quickly via e-mail at ``narten@raleigh.ibm.com''. Questions of a general nature concerning homeworks and programs and other aspects of the course should be posted to the newsgroup duke.cs.cps214 rather than sent as e-mail.

The grader for this course is Chong Xu (e-mail: chong@cs.duke.edu). His office is located in LSRC 104, phone: 660-6504.

Purpose

This is an introductory course on computer networking and distributed systems, with an emphasis on networking. It covers protocol design principles, performance considerations, and networking technologies. The goals are 1) to provide students with a broad theoretical and practical base in computer communication issues by considering all protocol layers involved in process-to-process communication, 2) to introduce students to the design issues and tradeoffs that arise in building and using networks for interprocess communication, and 3) to give students ``hands on'' experience with building and using distributed network services.

Prerequisites

A strong desire to learn about computer networking and programming experience with one conventional programming language (e.g., C, C++, Pascal, etc.). Programming projects will involve writing 200-500 line programs in C under UNIXgif. Warning: this course requires programming, but the focus is not on programming; although we will answer questions about the C/UNIX environment, you are expected to learn C and UNIX on your own. Basic probability and first year calculus will be needed for the first 1/3 of the course when we study data transmission and physical layer technologies.

Text Books

Required:

Computer Networks: a Systems Approach by Larry Peterson and Bruce Davie, 1996, ISBN 1-55860-368-9 (Morgan Kaufmann Publishers).

Computer Networks (3rd Edition), by Andrew S Tanenbaum, Prentice Hall, 1996.

Internetworking with TCP/IP: Principles, Protocols, and Architecture, Vol. 1, (3rd Edition), by Douglas E. Comer, Prentice Hall, 1996. [Note: we will not use this book until the second half of the course.]

Honorable Mention:

TCP/IP Illustrated, Volume 1, W. Richard Stevens, 1994, Addison-Wesley, ISBN 0-201-63346-9. (A potential alternate for Comer's text.)

TCP/IP Illustrated, Volume 2, Gary Wright & W. Richard Stevens, 1995, Addison-Wesley, ISBN 0-201-63354-X. (Detailed examination of the source code for the 4.4-Lite BSD TCP/IP stack.)

The C Programming Language, by Brian Kernighan and Dennis Ritchie, Prentice Hall, 1988.

The UNIX Programming Environment, by Brian Kernighan and Rob Pike, Prentice Hall, 1984.

Grading Policy

Final grades will be computed as follows:

Programming Assignments

The course will include four programming projects that reinforce material covered in class. Programs will be written in C (or C++) under Unix (Solaris, Linux, etc.). We will spend minimal time covering C and UNIX in class; novice UNIX users should purchase supplemental C and UNIX books and become comfortable with UNIX during the first two weeks of the semester.

Exams and Quizzes

There will be two in-class exams (including a final exam during Finals week), plus several pop quizzes for which no advance notice will be provided. Exams will be closed book, closed notes, but you are permitted to bring in one 3 by 5 inch index card covered with handwritten notes of your choice. The final exam will be comprehensive, but will concentrate on material covered following the midterm.

Written Homeworks

There will be six written homework assignments. Written assignments consist of problems from the book, made up problems, or readings from the research literature.

Late Policy

Each homework and programming assignment will be given a point value when it is handed out. The point value indicates the weight of the assignment relative to the other assignments. In general, homeworks and programs will not have equivalent weight. Late programs and homeworks will be penalized 3% per half day, and no assignments will be accepted more than seven days beyond their due date. We will cover material at a fast pace; it is inadvisable to fall behind. Programs are due at midnight of the due date and are turned in electronically using the UNIX turnin(1) command. Written homeworks are due at the start of class of the due date. Homeworks turned in after the start of class will be counted late.

Late homeworks can be left in my mailbox by giving them to the receptionist next to the mailroom (LSRC 138, Research Drive end of building). From the perspective of late points, an assignment is considered ``turned in'' at the point the TA or myself have it in our hands (which generally means the next day or later for homeworks slipped under an office door). To insure proper credit, deliver it to us personally, or have the receptionist note the time and initial your work. Exceptions to the late policy are possible in some circumstances, but must be made a priori. No assignments will be accepted after Wednesday, December 11 to allow sufficient time for grading.

Schedule

In the following schedule, numbers refer to topics referenced below. W1 refers to written homework 1, P1 refers to programming project 1, etc.

  1. Introduction, motivatoin, layering, OSI reference model, standardization, client/server, performance; physical layer (Fourier, Shannon, Nyquist).

    Reference: Comer: Chapter 1, Peterson: chapter 1, Tanenbaum: chapter 1  

  2. Physical Layer (continued): Multiplexing (TDM, FDM), encoding, clock synchronization, twisted pair, coax (baseband, broadband), fiber, phone, analog vs. digital, modems, wireless, isdn, satellites, X-kernel. Reference: Peterson: 2, Tanenbaum: (except 2.7).  

  3. Data Link Layer: Framing, Error Detection, Error Correction, Stop-and-wait, Sliding window protocols. Reference: Peterson: 3.1-3.5, Tanenbaum: 3.  

  4. Media Access Sublayer: Ethernet, Token ring, FDDI, device drivers Reference: Peterson: 3.6-3.9, Tanenbaum: 4 (except 4.2.7, 4.3.2, 4.4).  

  5. Network Layer: packet switching, forwarding, routing, datagrams vs. virtual circuits, ATM Cell switching Reference: Peterson: 4, Tanenbaum: 5.1-5.2, 5.6.  

  6. Bridges: spanning tree, token ring; Internetworking: IP datagrams, ARP, fragmentation, ICMP. Reference: Peterson: 5.1, Tanenbaum: 4.4, 5.4.  

  7. Internetworking: IP Addressing, subnetting, CIDR, routing (RIP, OSP, BGP)

    Reference: Comer: 4-10, Peterson: 5.2-5.3, 5.7, Tanenbaum: 5.5 (except 5.5.10).  

  8. Multicasting, End-to-end protocols: UDP, TCP, ATM (adaptation layers). Reference: Comer 11-17, Peterson: 5.5, 6.1, 6.2. Tanenbaum: 7.7.5, 6.  

  9. Remote Procedure Call (RPC), Domain Name System (DNS), DHCP. Reference: Comer: 21-22, Peterson: 6.3-6.5, 5.6, Tanenbaum: 7.2.  

  10. Data presentation, Security, firewalls, Socks, IPSec, compression Reference: Peterson: 7, Tanenbaum: 7.1.  

  11. Congestion Control Peterson: 8, Tanenbaum 5.3.  

  12. Applications: Telnet, SMTP (mail), FTP, NFS, SNMP, WWW. Reference: Comer: 23-28, Tanenbaum: 7.3-7.8.  

Cheating

Unless explicitly noted, all work is to be done on an individual basis. Any violation of the University's guidelines for academic integrity will result in a failing grade for the course and referral to the Student Affair's Office for disciplinary action. All programming projects and written assignments are to be your own work. You may discuss ideas, explain concepts, etc. in high-level terms with other students, but you may not discuss such specifics as what routines are needed, what arguments they should have, etc. Rule of thumb: You are encouraged to help students by explaining and teaching them material. If you help someone, the helped party should be able explain said material to a third party in their own words. If the helped party cannot, yet is able to turn in the assignment, both parties have behaved improperly. The first for providing too much detail, the second for turning in work they do not themselves understand.

About this document ...

This document was generated using the LaTeX2HTML translator Version 0.6.4 (Tues Aug 30 1994) Copyright © 1993, 1994, Nikos Drakos, Computer Based Learning Unit, University of Leeds.

The command line arguments were:
latex2html -split 0 syl.tex.

The translation was initiated by Thomas Narten on Sun Sep 15 17:08:33 EDT 1996


Thomas Narten
Sun Sep 15 17:08:33 EDT 1996