Dr. Dobb's Journal April 2000
Interconnections, by Radia Perlman, covers the protocols and algorithms that direct our data from halfway around the world or from the next room. Networking is no longer just for large corporations and big universities. Sun's slogan is "The network is the computer." These days, it's the Internet that's the computer. Hyperlinked online reference manuals are often easier to use than the print version. Most technical books list a web site for errata and updates. Networking is now part of the mainstream, both at home and at work. Routing happens under the hood just fine most of the time. (Even though I have a professional mechanic do most of the work on my car, I still need to lift the hood myself occasionally.) Interconnections is a good book for the weekend netadmin, those entering the profession, and for the inquisitive who like to occasionally look under the hood.
The book opens with the seven-layer Open System Interconnection (OSI) Reference Model. Although almost no networking protocol follows it exactly, it is useful for comparing protocols. This book deals mainly with the Data Link Layer (layer 2) and the Network Layer (layer 3):
In this book, the data link layer is relevant because bridges operate within it and because the service provided by it is relevant to routers, which operate in the network layers thereby making the network layer also relevant. The transport layer is somewhat relevant because it is a user of the network layer and because certain decisions that the network layer might make (such as whether to allow traffic to be split among several equivalent paths) affect the transport layer. The layers above transport are largely irrelevant to the study of bridges and routers.
Perlman has developed a number of today's significant networking algorithms and protocols. Her spanning tree algorithm is used by most link-layer protocols to prevent loops in the network. Given her authorship, she might be overly protective of it, but she covers its flaws too. She is not some objective observer (read disinterested) of the networking scene, she has been there, done that, is still there, doing that, and willing to share her experience. She is voicing an opinion and is not dogmatic about it. In some ways, that is the best part of this book.
Throughout the book, Perlman compares and contrasts various network protocols, both dominant (IP) and dying (DECnet):
Why do I bother describing protocols that are dying out? Why don't I just describe IP, which the world is basically converging on? There are a number of reasons.
I like this approach. I have never been much good at applying cookbook approaches. I need to understand something in order to work with it. If you just want to get a network up, this is not the book to reach for first. There are no examples of what programs to run or what files to edit to configure the routing tables (almost nothing here is OS specific). If you need to improve your network and have problems that the cookbook approaches don't cover, then this is the book to read.
The first edition of Interconnections compared protocols two at a time and left the detailed reference material to the RFCs (Request For Comments, in spite of the name, are the Internet standards). The second edition adds more protocols and reference information such as packet header layouts. In Chapter 10, Perlman compares seven protocols at once (IP, IPv6, IPX, IPX+, AppleTalk, DECnet, and CLNP). I found this overwhelming on the first read. Technical books generally require several readings. There is no way to discuss layered protocols without forward and backward references. Initially, I read the book cover to cover. While dipping back into this section, I found that with the forward references resolved it makes more sense.
The other problem in most technical writing is the information density. It is tempting to cover each detail only once, in precise, unambiguous language. This eliminates the possibility of contradicting yourself. The result is generally too dense to be readable. By adding discussions, well-reasoned opinions, and retrospectives, there is a redundancy that helps self-correct misunderstandings. The historical discussions show that turf wars, the "Not Invented Here" syndrome, and the marketing hype overwhelms technical content in standards committees too.
The chapter on network layer addresses also discusses the future. Much of the IP Version 6 Standard is complete and ready to be implemented:
Will the transition ever happen? That I can't say. I believe an IP with bigger addresses would have been more likely to happen if the IETF had agreed to accept the IAB's recommendation of moving to CLNP. At that time, CLNP had been implemented in all the routers and a lot of the endnodes, and IPv4 was creaking at the hinges. CLNP would have been just fine. But because the IETF wanted to invent something new, this delayed transition by several years. Customers had real, immediate needs. As a result, during the years the committee was designing IPv6, several critical improvements were made to IPv4, resulting in increasing its useful lifetime by a lot, perhaps forever.
I admit that after the first few formats in the "Connectionless Data Packet Formats" chapter, I started skimming. If you need them, this information is nice to have at hand rather than dig through the standards themselves. After the packet formats, Perlman covers the implications of the various choices for field sizes and meaning. For example, the Time To Live (TTL) field in IP and Lifetime field in CLNP are both specified in time units (seconds in IP and half seconds in CLNP). Both are intended to be decreased by each router. The purpose was to kill packets that wander in circles. She discusses why this doesn't work (the granularity is too coarse and the range is too limited). Instead, both are generally implemented as a decreasing hop count. She points out that even though this is her preferred implementation, there are situations where this doesn't work either, though they are much less common.
A problem that occurs in any distributed system is what happens when it changes (for example, links or routers go up or down, or are moved). The changes take time to propagate and settle on a new configuration. An example most of us have encountered is when a domain changes its IP address. The changes to all DNS servers can take weeks to settle down and the old and new IP addresses come and go several times like disturbed water in a shallow bowl sloshing back and forth. Perlman covers the solutions (mostly kludges rather than real fixes).
The general trend in Interconnections has been from older, more stable protocols to newer protocols and research areas. WAN Multicast is an area currently in flux, both the protocols and the need. Real-time net broadcasts add a heavy load. CNN's headline news is an example of where multicast will save a lot of web traffic. This chapter reads as though multicast is just an interesting research area. Perhaps reality has run ahead of the revision process.
Chapter 16 is about "Sabotage-proof Routing." This is a new area with no real standards yet. Radia outlines her approach and why it is needed.
When people think of a network component failing, they generally assume that it fails in a fail-stop manner -- that is, it reverts instantaneously from working properly to stopping completely. But a different sort of failure can and does occur, in which a node continues operating but functions incorrectly. This can result from software bugs, hardware faults or even sabotage. For example, a router might lie in its routing messages, misroute packets, reset the hop count, corrupt the data, perform perfectly except consistently trash packets from one source, or flood the network with garbage.
This sort of fault is known as a Byzantine failure. In this chapter, I sketch how a network can be designed to be resilient to Byzantine failures.
Ten years ago, this kind of stuff was for research and paranoia. What was once paranoia is quickly becoming safe computing.
The second to last chapter is a summary and asks, "To Route, Bridge, or Switch: Is That the Question?" One of the stated purposes of the book is to standardize the nomenclature for bridges, routers, and other switches. This chapter starts by comparing bridges and routers and then goes into extensions to each. Some of the extended bridges look suspiciously like routers and vice versa. The neat layers in the OSI model are not always preserved in actual protocols and implementations, and the distinction between a bridge and a router cannot always be made.
The last chapter is "Protocol Design Folklore," design principles with the examples drawn from various protocols. Almost every theme is applicable to any software design. It could almost serve as a checklist to run through after the design is complete. One of my new favorites is:
Every line of code should be exercised frequently. If there is code that gets invoked only when the nuclear plant is about to explode, it is possible that the code will no longer work when needed. Modifications may have been made to the system since the special case code was last checked, or seemingly unrelated events such as increasing link bandwidth may cause code to stop working properly.
Networks are like compilers; more people use networks rather than work on networks. Most computer-science and software-engineering students need to study both. If you are the curious type who likes to know what is going on under the hood, read Interconnections. Technical book access is like data access. Some need to be right at hand in the cache of books on your desk. Some need to be in the office. Others can reside in the library until needed. For networking implementors, Interconnections belongs on your desk while you are new to the field. After that you should continue to keep it on a bookshelf in your office.
Real-Time UML: Developing Efficient Objects for Embedded Systems, Second Edition, by Bruce Powel-Douglass, is about designing the processing in today's interactive programs as well as designing classic real-time systems. Twenty years ago, batch programming was mainstream and real time was just a niche. Today, interactive programming is mainstream. Much of what characterizes real-time and embedded programming (event-driven objects with state) is now mainstream. Batch processing was read, process, write. Early interactive programs were question, answer, process. Most GUI programs are modeless -- users drive the dialogue instead of the program. The Unified Modeling Language (UML) is a standard developed by Grady Booch, Ivar Jacobson, James Rumbaugh (the Three Amigos), and others in the software community under the auspices of the Object Management Group (OMG).
Any interactive program has real-time aspects. For example, try typing on a system that has slow and variable echoing of text to the screen. Your error rate will skyrocket, probably to the point of uselessness. The difference between two single mouse clicks and a double click is also a real-time issue.
Real-Time UML, Second Edition is about more than just notation. It also covers the analysis and design processes. The author wrote Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns in between the first and second edition of this book and some of that book is incorporated in the second edition. There is more coverage of process (analysis and design).
Much of the example code (almost all C or C++) has been dropped or shifted into UML. The UML diagrams now have more detail. There is a more mature, solid feel to the UML usage. It is the difference between a fluent speaker of a language and someone who thinks in the language.
If you are comfortable with the object orientation, there is probably enough about the nonreal-time aspects of UML to pick it up. Otherwise, read this book after a book on UML basics. The object orientation is a significant shift in how to look at programming. It cannot be picked up in a weekend or even a week-long course. This also means that you need to own the book(s), not just skim them in some bookstore or library. I bought the first edition two years ago. Some of the details in the second edition looked new, but had been there all along. It takes several readings and a lot of use to absorb it all. UML is a rich language and there is a depth that cannot be absorbed on the first go around.
There are places where the UML metamodel is introduced before the model has had time to gel and I found them confusing. After objects and association/links are understood, then is the time to introduce the idea that associations are metaobjects with metaassociations to the objects they connect. UML can be described in UML. This is a conceptually neat idea that permits a compact description. The UML standard itself is unreadably dense because the wording is abstract, so it can apply to several metalevels of the full model at once. My experience teaching programming and related subjects is that the student must be fluent at one level before proceeding from the concrete to a more abstract level.
There are only a few places where the metamodel is introduced too early. In layered models, it always helps to understand the layer above and the layer below the current layer. There is no way to do this without forward references or a horribly convoluted vertical tracing up and down through the layers. Software development, documentation, and teaching is an inherently difficult problem.
I like the author's choice of language. It is nicely precise without becoming mind-numbing weasel words. For example, "The actions in the action list are typically short, but in any case they run to completion before the transition completes." I would have written, "Actions on statechart transitions are atomic and uninterruptible." I like his wording better.
The author's cynical footnotes do not wear well with time. For example, "That is, the customer finally stops changing his or her mind long enough for you actually to build the darned thing." By now, I've seen them four or five times. They may have been funny the first time.
In general, the second edition is an improvement over the first. However, the proofreading slipped a bit. I found several index entries that were no longer correct. In the rewrite of the foreword, a key sentence was dropped. The grand duality mentioned is the differences between the descriptions of interobject behavior (use cases and scenarios) and the descriptions of intraobject behavior (statecharts), and the difficulty in moving between the two and showing them consistent.
The first edition is based on UML 1.1. The second edition was revised to match UML 1.3. The changes are small and mostly involve collapsing some special cases into the more general case. An appendix describes the OMG's ongoing work on real-time issues.
Every professional software developer needs at least a passing acquaintance with UML, even if your current project or employer is not using it. It is just part of staying current with the field. Some form of state diagrams, like statecharts, is also part of a well-rounded developer's education. This book and Doing Hard Time are the only books on real-time UML I turned up in a search of Amazon.com, fatbrain.com, and Barnes and Noble's web sites.
If you have the first edition, is the second edition worth buying? Not unless your copy has been borrowed by unknown parties. If you needed to read the first edition, I expect you need to keep some edition handy. If presented with a choice between the first and second edition, get the second, even if the first is available at a discount. If you used the first edition enough to wear it out, it is time to upgrade to Doing Hard Time -- real time for the hardcore.
DDJ