henry@utzoo.uucp (Henry Spencer) (07/08/88)
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
lm@laidbak.UUCP (Larry McVoy) (07/09/88)
In article <1988Jul8.012631.15892@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: [ Henry's notes about Comer's book being so-so but better than nothing ] > | Henry Spencer @ U of Toronto Zoology For what it's worth, I had a similar impression to the book. I've ported TCP/IP so I have some knowledge but there is a lot I was hoping to have cleared up by Comer's book. Unfortunately, I too am finding myself resorting to the RFC's for much of the detail. I'd say the book is a good thing to skim when one is starting out, but is a long way from being "the" reference. It's unfortunate, in a strange sort of way, that Prof. Comer did such an outstanding job with the Xinu books - it lead us to expect only the very best and perhaps made us a bit more critical of this offering than we otherwise might have been. -- Larry McVoy (laidbak!lm@sun.com | ...!sun!laidbak!lm | 800-LAI-UNIX x286)
bzs@BU-CS.BU.EDU (Barry Shein) (07/10/88)
Although I might be a tad unobjective I think people are missing the point (especially when I see people who have already done TCP/IP ports or otherwise dealt with networks in hand to hand combat say the book wasn't of total use to them.) Hang around the hallways of the ACE conference and listen to folks who came because they don't know a TCP from a UDP and have no mental model to begin to understand such things (typically their problem is that they don't know where the software/hardware boundaries are, which is not surprising if you think about it), or deal with students in a systems course (like one I teach here) trying to understand what all the fuss is about and missing the point repeatedly, or do consulting for a firm just getting into networking and try to just "quickly" go over how a network works and why they need these pieces and sophisticated consultants to design it and piece it together (um, why can't we just PLUG ONE IN...like a disk or something...well, I agree, but it ain't so, yet, at least not if you want more than an office or two hooked together.) If you think any of those folks can't benefit greatly from going thru Doug's book (and, conversely, could much benefit from a stack of RFC's plopped in front of them) then I think you're out of touch with his likely customers. And there's plenty in there to fill most "guru's" holes also (I freely admit there's more in there on EGP than I've had the time or patience to educate myself on, hey, we all have limits.) There's two necessary things to education: First, to provide the right questions, second, to provide the answers to those questions. I think Doug's book goes a lot further in providing the first part (the questions, the model to investigate, the motivations) than anything else I've seen thus far on Internetworking, and plenty far enough on part two (the answers) for a person to thereafter find their own way, at least after going thru the book they might think to ASK for an RFC. Beyond that, it's nice to know that it won't be the last book on networking. -Barry Shein, Boston University