Newsgroups: comp.protocols.tcp-ip
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: review of Comer TCP/IP book
Message-ID: <1988Jul8.012631.15892@utzoo.uucp>
Organization: U of Toronto Zoology
Date: Fri, 8 Jul 88 01:26:31 GMT

I acquired a copy of "Internetworking with TCP/IP" at Usenix and finished
reading it on assorted airplanes.  I have sufficiently mixed feelings
about it that I think it worthwhile to review it in detail.

Background:  I'm not a real TCP/IP guru, but might qualify as an apprentice
guru.  I learned about it originally by reading the RFCs (gak) and I work
on and maintain our local version, a variant of the KA9Q implementation.
I can't claim to be intimately familiar with all the details or to have
read the whole Protocol Handbook, but I know the outlines of most of it
and have combat experience with some of it.

The book emphasizes overall understanding of the protocols, although it
does cover a fair amount of detail.  The really fine points are punted to
the RFCs, for the most part.  It is meant to be useful as both a textbook
and a reference book, and generally strikes a happy medium.  It contains
coherent discussions of a number of issues that are hard to find in one
place otherwise.  Its appendix of implementation hints is worth the price
of the book all by itself, if you're going to be implementing TCP/IP.  It
is competently produced, with few botches (although some that remain are
serious, e.g. errors in RFC numbers in some of the Further-Reading sections
and a disastrous typo in Figure 4.1, the ONLY place where the decoding of
Internet addresses is explained precisely).

I wish I could recommend this book unreservedly.  Alas, I can't.

The fact is, this book has serious flaws.  First, most serious, and quite
possibly the cause of the others, is that it appears to have been put
together hastily as an expansion of a knowledgeable professor's skeletal
lecture notes.  The result is that while individual sections are okay,
they are not tied together well.  In particular, there are many cases
where something is referred to as if it had already been explained, when
in fact the explanation comes later or is entirely missing.  The appendix
on the Berkeley interface refers offhandedly to the fact that a connection
is characterized by both its endpoints, and hence more than one connection
can be active on the same port -- but this important and subtle concept is
NEVER discussed in the text proper!  The discussion of the name server
protocol suddenly starts using variable-length strings without explaining
how they are encoded... that comes later, in the section on the compressed
name format!  The chapter on ARP never does explain the PROTOCOL field.
These are not isolated examples; this sort of thing happens continually,
and makes the book very frustrating to read sequentially.  I already knew
enough to make this only an aggravating nuisance; a real novice would, I
think, find it very troublesome without external help.

Okay, so this hurts it as a textbook.  Is it useful as a reference book?
Same answer:  yes and no.  The trouble with it as a reference book is that
too many details are left out.  There are several references to the Karn
algorithm for RTT estimation, but it is never discussed; describing it
precisely and giving an outline of why it's good would take only a page
or two.  The three-way handshake for TCP connection establishment is
explained, but the handshaking for closing a connection is never really
explained; the state diagram from RFC 793 would take only a couple of
pages to show and tersely explain, but this is never done.  The urgent
pointer is brushed off in one sentence that does not really explain how
it works.  While it isn't really realistic to expect a book of this size
to replace the Protocol Handbook, this book would be an order of magnitude
more useful as a reference if it included 10% more detail.

A lesser, related problem is inconsistent level of detail.  The lower-
level protocols are explained in considerable detail, while the high-level
ones are crowded into a chapter or two that permits only a hint at the
overall flavor of a few of them.  The level of detail is inconsistent
even within discussions, with detailed message formats sometimes given
and then accorded only a quick hand-waving explanation.

One last annoyance in using the book as a reference is that the textbook-
oriented exercises at the end of each chapter sometimes raise important
points that one would hope a reference book would discuss more explicitly.
The implementation-hints appendix resolves some, but not all, of these
loose ends.

Overall, this book would be acceptable as a textbook for a course taught
by a knowledgeable professor who can fill in the gaps and smooth down the
rough edges, or as a self-study text for a bright student who knows
something about the topic already and has access to a copy of the Protocol
Handbook.  I cannot recommend it for self-study in general, and as a
reference its usefulness is limited.  It seems to me that many of the
problems arise from it being prepared in haste.  I would look forward
eagerly to a second edition, slightly expanded, thoroughly revised for
completeness, coherence, and consistency, and preferably tested on an
unassisted novice before publication.  That second edition could be a
truly superb first book on TCP/IP; the first edition is rather mediocre,
and is the clear choice only because there is no other.  It's really
unfortunate that the publishers are succumbing to the computer builders'
bad habit of letting their customers debug their products.

All that being said, this book *is* a lot better than nothing.  I learned
quite a bit from it, despite the problems.  If you are considering buying
it, either for yourself or a course, I would say "go ahead... cautiously".
-- 
                                     |  Henry Spencer @ U of Toronto Zoology
                                     | {ihnp4,decvax,uunet!mnetor}!utzoo!henry