|
|
|
|
|
|
This course introduces the basics of networking,
ranging from sending bits over wires to the Web and
distributed computing. We focus on the
internetworking ground between these two extremes,
particularly focusing on the engineering of
the Internet - goals, constraints, solutions, and
experiences. The outcome of this course for you
should be an appreciation of the fundamental challenges
of networking, design strategies of proven value, and
common implementation technologies. Topics will
include: framing, error correction, packet switching,
multi-access (Ethernet), addressing and forwarding
(IP), distance vector and link state routing, queueing
and scheduling, reliable transport, congestion control
(TCP), quality of service, naming (DNS), and security.
|
|
Course Structure
It's likely that there will be elements of this course that aren't quite what
you were expecting. Some explanation of what is going on, structurally, may help in
understanding what to concentrate on, should things get murky.
There are basically three main threads to the course.
The first is learning the specifics of how the major Internet components are built
and operate. This means, for example, learning about IP, BGP, TCP, DNS, and HTTP.
Becoming familiar with these specifics is important,
they affect and explain a lot about how current systems are built.
This thread is most directly addressed by the text and the lectures.
The second thread is a more general set of concepts/problems that arise whenever
networking is involved, that is, abstracting from the specific Internet solutions
to the more general problem and its potential solutions.
You'll confront these problems every time you write any networked code, and so
understanding what they are is another important goal.
The burden of this thread falls most heavily on the project assignments (although it's
also addressed by the text and lectures). In particular, we'll build a sequence of
projects that, in a sense, recreate major components of the Internet,
but using the Internet instead of wired
or wireless hops as the basic transport. (It's stretching the scope of the projects
a bit, but this is generally referred to as an overlay network.)
So, you'll be confronting the same problems the Internet faces, and solving those
problems in ways similar to how they're solved by the Internet, but it might take some
reflection to understand how the project work and the Internet specifics are related.
The final thread of the course has to do with the computing platform. It is arguable
that "the standard platform" of (literally) tommorrow is the phone + cloud. Particularly
in a networking course, it seems worth the modest learning-curve overhead required to
gain experience with something close to that platform, so that's our plan. We'll simplify the
cloud down to a single server, but for the phone end we'll use phones. In particular,
we'll build applications for Android (2.3) phones. As mentioned, there is some overhead
to this, but the projects are structured to help with that. (This course is not intended
to be a deep examination of phone programming; it's just an introduction.)
|
|
|
Officially Required
- CSE 332 (or 326)
- CSE 351 (or 303)
Recommended
- CSE 333: for systems programming experience.
- CSE 451: because concurrency is inherent in networking.
I'll assume you know nothing about Android programming. I'll assume you know a little bit
about concurrency and threads (from 332). The course projects use threading extensively;
having had CSE 451 is likely an asset, although the course is designed and paced assuming
you have not had it.
There are likely to be a lot of "details" involved in the completing the projects
that are not spelled out in the course materials. (For example, we'll use Eclipse as
the development environment, but won't try to explain everything you can do with it.)
It's normal and expected that you will consult whatever resources might be most useful
to you when you encounter a detail that gives you trouble. Those resources include us
(the course staff), other students in the course, other students not in the course, the
web, books, and whatever else you'd like. (Note that this is not intended to condone
copying code from other students,
hiring people to take exams for you, or other activities intended to
avoid the very not-detail core of the course. It's about the million practical details
that can arise (or not) whenever you try to write or use software.)
|
|
There will be up to three kinds of
assignments given throughout the class:
- Reading: you will be given reading
assignments from the course textbook associated with each lecture. You
should try to finish the reading before coming to the lecture.
We will be covering a large fraction of the topics in the text. It won't
be easy to catch up if you fall behind.
(From time to time the text may be supplemented with additional reading.)
- Textbook(-style) questions:
Some assignments may include questions
from the text, occasionally supplemented with similar questions I invent.
- Projects: You don't want to come out of
a networking course having never once written code that sends data across an actual
network. You won't.
The implementation language is basically Java,
as supported and supplemented by Android 2.3.
The default development environment is Eclipse.
In theory, the project infrastructure we distribute should run on both Linux
and Windows (and Macs, I'd guess), but we'll be developing and testing only on Linux.
Projects will be done in teams of two. You can switch partners between
projects. As I write this, I don't plan on the projects being cummulative (you don't have
to have a perfectly correct Project N-1 to work on Project N).
We'll run on both the Android emulator and actual phones. The phones are limited, though, and
we have only enough for one per team. If you have a personal phone running Android 2.3.3 or later,
you should be able to use that.
This is a 4 credit hour course, meaning that it deserves something like
12-16 hours of
your undivided attention per week. Try to reserve hours for the reading and stick to
your schedule, even if some programming assignment that isn't going as well as you expected
(i.e., all of them, for all of us) is coming due shortly.
Start projects early. There are countless things that can go wrong. Run into those
things early, when you can afford to suspend working until you get help, rather than 4 hours
before the project is due.
|
|
There will be
one midterm and a final exam for this course. The dates are subject to
change, with reasonable advance notice.
- Midterm: Wednesday, April 25
- Final : Thursday, June 7, 2:30-4:20
|
|
|
I reserve the
right to "fine tune" this later, but grades will be assigned roughly as follows:
- Assignments/Projects: 55%
- Midterm: 15%
- Final: 30%
|
|
(Many of these policies are taken
verbatim from previous instances of this course.)
- Late Policy: There is a 10% penalty for each
late day, or portion thereof. You get two free late days - two days of lateness
with no penalty - to use at your discretion. (That's four days total for a team of
two.)
- Reasonableness: No set of rules
can apply perfectly in every setting. Reasonable exceptions can be made.
- Cheating vs. Collaboration:
Collaboration is a very good thing. On the other hand, cheating is considered
a very serious offense, and is vigorously prosecuted. Vigorous prosecution
requires that you be advised of the cheating policy of the course before the offending
act. For this course, the policy is simple: don't cheat. You know it when you're doing it.
We'll recognize it when you do it.
That said, collaborating is, for many people, an effective way to learn. Learning
isn't cheating. Misrepresenting that you've learned something, or done the work
that implies you've learned something, almost certainly is.
|
|
|
|
CSE Home
