195
ns is derived from earlier simulation projects such as REAL and has gone through a couple of incarnations. The kernel is written in C++, while user scripts are written in MITs Object Tool
Command Language OTCL, an object-oriented version of Tcl. With any simulation software, you should expect a steep learning curve, and ns is no exception. Youll need to learn how to use the
product, and you will also need a broad knowledge of simulations in general. To use ns, youll need to learn how to write scripts in OTCL.
Fortunately, the ns project provides a wealth of documentation. The Unix manpage is more than 30 pages and displays the typical unreadable terseness associated with Unix manual pages—great for
looking up something you already know arguably the intended use but abysmal for learning something new. There is also a downloadable manual that runs more than 300 pages. However, the
best place to start is with Marc Greiss tutorial. It is a more manageable 50 pages and introduces the scripting language in a series of readable examples.
One problem with simulations is that they can produce an overwhelming amount of information. Even worse, simulation results describe dynamic events that are difficult to interpret when viewed statically.
nam is a visualization tool that animates network simulations. It is hard to convey the real flavor of nam from a single black-and-white snapshot, but
Figure 9-1 should give you some idea of its value.
Figure 9-1. nam example
This is output from one of the sample scripts that comes with the program. The basic topology of the network should be obvious. Packets are drawn as colored rectangles. Different colors are used for
different sources. As the animation is played, you see the packets generated, queued at devices, move across the network, and occasionally, dropped from the network. Node 6 in the figure shows a stack of
packets that have been queued and one packet below the node that has been dropped. Dropped packets fall to the bottom of the screen. The control buttons at the top are used just as you would
expect—to play, stop, or rewind the animation.
NISTNet, ns, and nam are all described as ongoing projects. But all three are more polished than many completed projects.
9.3 Microsoft Windows
196
Few of the tools described in this chapter are available for Windows. Those that are available include some of the more ambitious tools, however. In particular, ns and nam have downloadable binaries for
Windows. According to the mgen documentation, a Windows version may appear shortly. netcat has also been ported to Windows.
If you are interested in traffic generation for loading purposes, you might look to ipload. This is a very simple program that will flood a remote device with UDP packets. You can specify the destination
address, destination port, packet rate, and packet payload. As the program runs, it will display a window with the elapsed time, the number of packets sent, the packet rate, and the number of bytes
per second. ipload comes from BTT Software in the U.K. and requires no installation.
Several network-oriented benchmark programs available for Windows might also be of interest. In particular, you may want to look at NetBench, which can be downloaded from Ziff Daviss web site,
http:etestinglabs.combenchmarksnetbenchnetbench.asp . It is designed to test clientserver
performance. Youll need to download both client and server versions of the software.
197
Chapter 10. Application-Level Tools
This chapter briefly surveys some additional tools that might be of interest. You will not need tools that are useful when setting up and debugging programs using application-level protocols. The chapter
is organized around different application protocols. You will not need the tools described here often. The goal of this chapter is to make you aware of what is available should the need arise, and the
approach described here may be more useful than the specific tools mentioned. Unless you have a specific problem, youll probably want to just skim this chapter the first time through.
10.1 Application-Protocols Tools
Many network applications are built upon application-level protocols rather than being built directly upon network- or transport-level protocols. For example, email readers typically use SMTP to send
email and POP2, POP3, or IMAP to receive email. For some applications, it is difficult to distinguish the application from the underlying protocol. NFS is a prime example. But when an implementation
separates the application from its underlying protocol, a number of advantages can be realized. First, the separation helps to ensure interoperability. A client developed on one platform can communicate
effectively with server software running on a different system. For example, your web browser can communicate with any web server because it uses a standardized protocol—HTTP. Tools based on the
underlying protocol can be used to obtain basic information regardless of the specific application being used.
Most of the tools described in this chapter collect information at the protocol level. While it is unlikely that any of these tools will provide the detailed information you would want for a problem with a
specific application, they should help you identify where the problem lies and will help if the problem is with the protocol. Most applications will have their own approaches to solving problems, e.g.,
debug modes, and log files. But youll want to be sure the problem is with the application before you start with these. If the problem is with the application, youll need to consult the specific
documentation for the application.
If you are having trouble setting up a network application for the first time, you are probably better off rereading the documentation than investing time learning a new tool. But if youve read the directions
three or four times in several different books or if you have used an application many times and it has suddenly stopped working, then its probably time to look at tools. For many of the protocols, youll
have a number of choices. You wont need every tool, so pick the most appropriate, convenient tool and start there.
Providing a detailed description of all available tools is beyond the scope of any reasonable book. This would require both a detailed review of the protocol as well as a description of the tool. For example,
Hal Sterns 400-page book, Managing NFS and NIS, has three chapters totaling about 125 pages on tools, debugging, and tuning NIS and NFS. What Im trying to do here is provide you with enough
information to get started and handle simple problems. If you need more information, you should consider looking at one of the many books, like Sterns, devoted to the specific protocol in question. A
number of such books are described in
Appendix B .
Generally, these applications are based on a clientserver model. The approach youll take in debugging a client may be different from that used to debug a server. The first step, in general, is to
decide if the problem is with the client application, the server application, or the underlying protocols.
