Q & A on Writing a Network Analyzer,

Q: I'm interested in exploring the idea of writing one's own analyzer. What do you use for this, the Berkeley packet library?

A: The grad students use my operating system, Xinu. We give them a device driver that can put the NIC in promiscuous mode to receive packets; they build the rest inside the kernel. Undergrads use snoop to capture frames, put them in a file, and then decode them offline (there are packet traces on the CD-ROM that comes with the book if you want to try decoding headers but don't have direct access to the driver).

Q: Also, I've just recently become more interested in networking, and I'm pretty much teaching myself this stuff. I was wondering what kind of approach you'd recommend for this type of education. I've read your TCP/IP Volumes I and III, as well as the RFCs for TCP,IP,ICMP. It's a bit of a curve, but once you read a few you want to read them all. I enjoy just reading the specs. What I guess I really need is a big project.

A: Yes, the only way to really appreciate the subtleties is to build. You can do packet analysis to find out about header details of existing protocols or watch traffic, but I suggest trying to implement a reliable protocol. If you don't have low-level facilities available, start with UDP -- build your own protocol and use UDP as a 'delivery' mechanism. Then, place an intermediate application between the two sides that delays, reorders, duplicates, or purposefully damages a few bits. See if you can design a protocol that detects/corrects the problem.