This chapter describes Netdude's architecture. It is intended for users that consider writing their own plugins, to provide a deeper understanding of how things fit together. Reading it is not strictly necessary when you only want to use Netdude with its off-the-shelf features.
Starting with the 0.4 release, Netdude's architecture has become much more modularized. There is now a clear separation of packet manipulation and GUI functionality. The following diagram illustrates this:
Netdude's architecture.
The next layer is the heart of the system, the packet manipulation code. It lives in a standalone library, libnetdude. libnetdude provides data structures and APIs to create and manipulate arbitrarily large traces, packets, trace parts, trace navigation, protocols, tcpdump output, and packet filters. Individual protocol support is provided through plugins, actually dynamically loaded shared libraries. Each loaded trace is associated with a tcpdump process that can be used to obtain tcpdump output for individual packets.
Netdude itself provides only the GUI and links in libpcapnav and libnetdude. The way protocol headers are represented is again defined through plugins to maintain modularity. Events in libnetdude are passed up to Netdude using an observer pattern — Netdude registers observers with libnetdude which then reports packet and trace modifications to Netdude.
[1] | Bravely following Murphy's Law, the author's initial testing took place using a trace that contained network traffic created by copying a trace file via NFS. Hence the resulting trace contained lots of additional libpcap packet headers, which mightily confuses tcpslice. |