[beej71]

Hey everyone! This newer guide is basically what I wrote for teaching an Intro to Networking class last year. And I decided instead of keeping it locked away in the LMS I'd put it online for everyone.

Where the other, more popular guide is basically an intro to the C sockets API, this is more about networks in general.

There are certainly a large number of errors to still be found, and I'd love to hear about them if^H^Hwhen you find them.

The goal, as always, is ad-free and correct-as-possible. :)

[planckscnst]

I'm excited for the new material. Thank you for releasing it!

[mekoka]

Hey Beej, do you have a guide on how you write a guide? I've been amazed by your output, both in quantity and quality.

[beej71]

I'm sure everyone has their own approaches for this kind of thing, but mine is basically this:

Try to remember what was difficult about this material.

Use that to guide yourself down to the core pieces. What is the kernel at the center of this mass of knowledge? "This would have been easy to learn if only... [what?]"

Often if you view the particular ecosystem as a dependency graph, the places to start are the root dependencies. If you go back far enough, there tends to be a single root.

Make sure that core foundation is well-covered and answers all those questions that made the material difficult when you learned it.

Then add some more use cases on top of it just to give the reader ideas of what they could go on to build. This won't be comprehensive, but should be tempting.

The very act of _learning to program_ should be exciting and fun. I recall when I was 12--every page of a programming book was unlocking something else in the world. "Wait--it can do _that_?" I try model this more as a path to follow at first and less of an open field going off in all directions. And I try to _hint_ that it _is_ actually an open field going off in all directions, but the reader can explore that later.

Don't worry about being wrong. Make an effort to be right (pride in quality) of course; just remember that everyone who produces a laundry list of reasons why your guide is crap and you shouldn't be allowed near a keyboard has just given you some free editing. :) If the points aren't valid, you can ignore them. If they are valid, you learn something (win), the guide gets better (win), everyone who reads it after the fixes gets better-quality info (win), and the complainer can no longer complain about those things (win). And ask Brian Kernighan or Rob Pike if they've ever published something wrong, and I guarantee they'll laugh knowingly. :)

My tone--I imagine I'm being a goofball discussing this with one of my best friends. I like that tone, I have an easy time writing in that tone, and it seems to be pretty popular. But I've also definitely had people complain about it being too casual. I don't know what to say, other than...

We're knights of the round table

We dance whene'er we're able

We do routines and chorus scenes

With footwork impeccable

We dine well here in Camelot

We eat ham and jam and spam a lot

Dah dah dah da da dah dah... [dude clapping in the dungeon]

Also, don't forget to reread and rewrite everything. There's always room for improvement.

[sebstefan]

Your site carried me through my network modules in undergrad. Thanks man