Posted
by
samzenpus
on Wednesday December 14, 2005 @02:52PM
from the read-all-about-it dept.

FrazzledDad writes "Network geeks and developers working in the TCP/IP domain are most likely familiar with Douglas Comer's Internetworking With TCP/IP Vol.1. Comer's book was central for my understanding of how things really worked in the small corner of a world-wide network I use to manage. Charles Kozierok's The TCP/IP Guide has knocked Comer's book off my shelf. Kozierok's weighty book (1600 pages!) does a terrific job both as a reference and as a learning aid." Read on for Jim's review.

Kozierok spent at least four years working full-time on this book, according to the dedication, and it shows. He covers everything from networking fundamentals to individual application protocols such as Gopher.

Do you need to familiarize yourself with Open Shortest Path First (OSPF) routing protocol basics? It's covered. Do you need to understand the pros and cons of Network Address Translation, and how static and dynamic mappings work? It's covered. Do you want the nitty gritty of how message formats are laid out? It's covered.

Kozierok also presents several chapters specifically on IPv6, laying out changes in the new version before diving into the nuts and bolts of it. He discusses the major additions, and dedicates an entire chapter to the new addressing scheme. The transition from IPv4 to IPv6 is a well-written section talking about the difficult conversion between the two versions.

THE BOOK AS A LEARNING GUIDE

TCP/IP can be a rather dry topic to read about when trying to learn portions of it. Let's face it: reading about BOOTP's messaging over UDP is not something most folks will give up a Friday night on the town for. OK, Kozierok's writing style won't make that happen, but he does keep things interesting and flowing well enough that working one's way through such topics is actually entertaining instead of torture.

For example, Chapter 18's discussion of subnetting concepts lays out the fundamentals in clear order without sliding into unfathomable academic blabberspeak. His use of "Key Concept" boxes throughout the book helps point out important items.

Just as important to the book's clarity and usefulness are the amazing graphics. In the Acknowledgments Kozierok specifically thanks the folks at SmartDraw.com for their illustrating package. He's put the tool to fantastic use for everything from breaking out the control bits from a TCP segment header to showing how iterative DNS name resolution works.

THE BOOK AS A REFERENCE

The level of detail in the book makes it a valuable reference in addition to its role as a learning guide. For example, readers can find specifics on details of SNMP data types, NFS server procedures, or TCP segment format layout. Additionally, Kozierok discusses many of the various TCP/IP utilities, such as using "netstat" for troubleshooting with a detailed discussion of various outputs.

Kozierok must have spent a lot of time figuring out how to best lay out the book, and it pays off with sensible organization. Two tables of content, one brief and one detailed (32 pages!), help one to get to the right spot to look up needed information. The index is nearly 50 pages and seems to be quite exhaustive; another great tool for getting to the right spot. There are also comprehensive lists of Figures and Tables if you're trying to access something via that route.

WHAT IT DOESN'T COVER

Kozierok is upfront about things he's left out of the book. You'll need to look elsewhere (back to Comer's book, perhaps) for details on TCP/IP in ATM networks, security and firewall design, and the lower levels of socket usage.

CONCLUSION

To me, a significant advantage of this book is No Starch's binding system that they make so much hay about. I can open this massive book to any point and leave it flat on the table. Pretty impressive!

Kozierok also has a companion website (www.TCPIPGuide.com) with errata, a FAQ, and various other areas. You can also purchase an electronic copy of the book.

The TCP/IP Guide is a tremendous work, and it's a significant resource for anyone working with TCP/IP."

I agree, the new updated version of TCP/IP Illustrated covers everything from IPv4 to the latest and greatest TCP newReno and Vegas.Combine this with Design and Implementation of FreeBSD and the 2 Unix Systems Programming book from Richard Stevens, you have the most comprehensive book collection on networks. Want a slightly more hands on approach, look at the source code for the TCP stack in FreeBSD.
If you wanted a more general approach pick up any networks book from Kurose, tanenbaum etc.
Now if somebo

True. It is the "all your karma are belonging to us" aspect of slash based forums that bugs me. So far it has not seemed heavyhanded enough to send me back to sifting through the volumes of crap on Usenet to try to find anything valuable.

I'm with you. I am entirely serious when I say the slashdot M1 system, and the fact that some people think it's working are more of a source of amusement to me.

It's not that the most of the moderators are shit, either - I'm sure that's not the case.

I believe it's because the whole M1 system is fundamentally fucked up. The most boring of points go from Score 1 to Score 5 immediately due to people looking at pages that are 30 seconds old, and moderating them. Then the "Underrateds" hit and drive things b

Now, I always heard that Comer was the last word, and I picked up the three volumes years ago, and on and off have worked at them.

However, in a phone interview recently, I was told that the tear-down on a TCP/IP session was a four-way handshake. Websites I was pointed also said this. But when I go to the Comer, Vol. 1, it says that it's actually a six-way: a three-way from the originator, and a three-way from the recipient.

Agreed. Real men don't need to read a sissy book with non-ASCII-art pictures and diagrams. Especially none with obscure animals on the cover. Real men have the RFC printed out and bound with a big black clip.

Well, that's $30.00 cheaper than what I paid for it at Border's. However, I found the book so captivating I picked it up right then and there. I've been looking for a comprehensive book that explains the nitty-gritty of TCP/IP and this is it! The author uses many illustrations to solidify his book's textual content where mere text will not suffice. I'm not more then 10% into the book, yet, and already it's become one of my most treasured books in my library.

It is worth mentioning (since the reviewer didn't) that the book is available free online in HTML format. Start with the table of contents [tcpipguide.com]. He also sells (erm, "licenses") PDFs for $35, though I'd rather buy the book itself for $50 at Amazon. The HTML version has those annoying fake-link ads that pop up sundry advertisements when you mouse over them, but I still commend him for posting the book. I have bookmarked it for future reference, and I'll likely buy the book if it proves more useful than the RFC

At least it's not as bad as the Unix manual we had in one of the CS labs. It was mounted on rails and bolted to the table (taking up 90% of the length of the table).

My theory was that it wasn't bolted to the table to keep people from taking it, but rather to keep it from falling off and killing someone when it landed on them. I can just picture the legs of some poor freshman sticking out from under that paper monster, the rest of him having been squished into jelly from the book's sheer weight...

Business majors would have to be pretty far out of their normal stomping grounds to see it. It was on a floor with almost nothing but unix and matlab labs in a building that most business majors never saw more than the first two floors of if they saw it at all:P

If it were closer to the business majors, I might have had the theory that the book was bolted to the table to make it more difficult to beat MBA's with =]

We had a VAX donated to us a little while ago. This wasn't a MicroVax, but it was one of the smaller ones - about the size of small fridge. Along with it came a couple of dumb terminals, and the documentation. In spite of the size of the machine, the documentation that came with it took up more space.

Oh, and saying *nix falls short of VMS in a couple of areas is like saying DOS falls short of *nix in a couple of areas...

I'll agree, I thought it was a great book to read about TCP/IP. A lot of very good information in my opinion. Just at the time I picked it up it was as a loaner from the public library, so didn't get a chance to get as involved with it as I would have liked to. Been too lazy to pick up my own copy.

Interesting that the Wikipedia entry misses the Second Edition of Advanced Programming in the UNIX Environment [amazon.co.uk] - my own personal favourite reference book. This is the book to read for cross-platform programming - it covers POSIX and SUS standards as well as giving details on the implementation of these standards on Linux, FreeBSD, OS X and Solaris. It covers pretty much everything that a low-level (userspace) coder needs to know for writing code on *NIX.

When i was in college, TCP/IP was just starting to get big. we were moving from Novel and BITNET (we were even a major BITNET to TCP/IP gateway). At first, i played with ftp sites, found ARCHIE. Then gopher, followed very quickly by the WWW. I played with gopher a bit, but being exposed to it around the same time as the WWW, it's limitations were very obvious. Eventually, gopher servers went away and the gopher protocol became nothing more than a way to DOS Netscape (gopher has no concept of content-

Although not technically a PDA (it's an Internet Tablet - a PDA without PIM functions), the Nokia 770 is a fun toy. I got one on the developers program, and have been playing with it for about a month. The screen is gorgeous and it runs Linux/X11. They have 802.11g support as well as bluetooth for connecting via a mobile 'phone.

well, as it really is so, it might be too much flashing all around or all those subpages, but the contents doesn't look to me half as complete as a handful of other books I've seen on the matter; very good to have a web reference when needed (I'll remember to follow some ads), but I personally wouldn't buy the book based on a first sight on the website.

I wrote to him to discuss something I'd noticed in the IPv6 sections, and he wrote back. It was very nice to discuss it with him directly, and I'll gladly echo the fact that his work is both easy to read and informative.

I've read a LOT of networking crap over the 25 years I've been doing computer networking, this ease of reading is not common to the genre.

Just curious... Why does one need a book (especially 1600 pages long)? Does it cover something that's not in the RFCs?

I guess what I'm thinking is that TCP/IP networking is hardly rocket science. Surely the basics can be described in just a few pages. For everything else, you're going to have to look at specs anyway.

Am I missing something? Or are network prototcol programmers jealous of the multi-thousand-page-red-softcover-with-the-author' s-face-on the-cover books that the MSofties have on their desks collecting dust?

1. 1600 page books look impressive.2. Keep the information hidden. bury it in useless data and it is hidden in plane site.3. Make TCP/IP look 1000x more complicated than it is. Network Engineers get paid more.

1600 pages for something that would have to have a lot of fluff to fill half that and could probably be covered really well in 1-200 pages.

I love it when dolts who have never done anything criticize folks with actual achievements. Talk is cheap- I challenge you to write a 200-page book that covers the same material thoroughly.
Tell ya what- I don't feel like waiting, 'cause even 200 pages takes time. I challenge you to authoritatively teach one thing, like the snm protocol, in 1000 words, or whatever you think you need. Post a link to it here, I'll check back.
you won't, and you'll make excuses is my prediction.

In other words, you have no idea how to write a book either. Nor have either of you read the review book to see if it offers any value beyond re-hashing the RFCs.
Yeah I know, this is Slashdot, what do I expect.

The basics of anything can be described in a few pages for some level of "basic".

For my thesis I described the basics of TCP/IP in about 20 pages; however, when onse is making changes to the TCP stack itself, the basics just will NOT do. I have hit several of the in-dept chapters of the Steven's volumes multiple times. Some times I find those books lacking in the detail I need.

These are not "admin" style books. Most TCP/IP protocol suite implementations are very large and complex.

"How long does it take to download The TCP/IP Guide?
About 2.5 hours using a 28.8kbps dialup modem; about 1.3 hours at 50kbps; about 8 minutes with 500kbps broadband." (http://www.tcpipguide.com/faq.htm [tcpipguide.com])

A lot of people in the UK who still use modems do so because they live too far away from the exchanges to get a real Internet connection. People in these situations are likely to be using lines that are multiplexed to the hilt. In my parents' last house, it was impossible to connect at more than 28.8, and 26.4 was more usual. For these people, 28.8kbps is a good indication. Mind you, I get a faster connection via my mobile 'phone these days...

I use older slower modems during storms all the time. They'll stay online when a 56k craps out from line noise., plus, if they get fried, meh, another thriftstore, another 50 cents.Oh ya, if you live rural, it's a real bother to try and find "broadband" in the US. It just ain't happening except for very expensive and very limited satellite "service". Cable is unobtanium and DSL means you have to be two miles or less from a telco box, which barely qualifies as suburban, let alone "rural". I think when/if Wi

"Internetworking with TCP/IP" is good, but "TCP/IP Illustrated v.1" is outstanding.

For many years until a RFC was published, the "official" reference (for example, to quote in an article or book) about TCP's fast retransmit and fast recovery was Stevens' book, unless you wanted to quote the original Usenet post for Van Jacobson.

I used Comer & Stevens to learn about TCP/IP. along with Postal (ie the RFC's). But a hidden gem is the IBM Redbook "TCP/IP Tutorial and Technical Overview" [ibm.com]. From that link you can download the PDF of the 980 page book - all for free. or you can order the hard copy book

Well considering the time (and space) based nature of networking. Getting away from books (and their limitations) and towards a more dynamic form of presentation would be best. We already try for this by buying all this hardware, and downloading lots of software. All so we can sit with our networking books propped right next to it.

Yup - we do. And only time will tell us whether ink on pulped wood is a better medium for reference than electronic media, or whether us old-timers just like it by habit

I haven't seen this book, but I did like the Comer's one, and personally I don't like the Stevens' one -- mostly because it's too thick. With the technical books like these it is very easy to stray away from concepts explanation into dull recital of RFCs/manpages/etc. growing your book's pages count, but making it less useful. From the review, I understand that this new one has a similar tendency. Did it knock the Comer's book of your shelf just because it had a heavier weight then? Or for some other reason

Volume 1, and do more than cover just TCP/IP standards, they also have a practical implementation aspect. Of course, its all Cisco based, but given a huge whack of the networking is as well, that's not as big a disadvantage as you'd expect. For BGP (especially Cisco's implementation of BGP), look to the CiscoPress "Internet Routing Architectures". I prefer it to the coverage in Volume II of Routing TCP/IP.

Well, I scanned it in depth.The gold standard is still "TCP/IP Illustrated", Stevens, even though it is getting somewhat long in the tooth. The Kozierok book is essentially all prose descriptions of how the TCP/IP stack works, no code. There is simply no replacement for Stevens if you need to figure out how the stack is dealing with multicast packets or dozens of other situations.

There are some questionable organizational choices, such as starting of with SLIP and PPP in the first chapters. And gopher is pr