diff options
Diffstat (limited to 'Documentation/RelatedWork')
| -rw-r--r-- | Documentation/RelatedWork | 87 |
1 files changed, 0 insertions, 87 deletions
diff --git a/Documentation/RelatedWork b/Documentation/RelatedWork deleted file mode 100644 index ed7dba8..0000000 --- a/Documentation/RelatedWork +++ /dev/null @@ -1,87 +0,0 @@ -Work that relates to netsniff-ng and how we differ from it: -/////////////////////////////////////////////////////////// - -ntop - * W: http://www.ntop.org/ - - The ntop projects offers zero-copy for network packets. Is this approach - significantly different from the already built-in from the Linux kernel? - High likely not. In both cases packets are memory mapped between both address - spaces. The biggest difference is that you get this for free, without - modifying your kernel with netsniff-ng since it uses the kernel's RX_RING - and TX_RING functionality. Unfortunately this is not really mentioned on the - ntop's website. Surely for promotional reasons. For many years the ntop - projects lives on next to the Linux kernel, attempts have been made to - integrate it [1] but discussions got stuck and both sides seem to have no - interest in it anymore, e.g. [2]. Therefore, if you want to use ntop, you are - dependent on ntop's modified drivers that are maintained out of the Linux - kernel's mainline tree. Thus, this will not provide you with the latest - improvements. Also, the Linux kernel's PF_PACKET is maintained by a much bigger - audience, probably better reviewed and optimized. Therefore, also we decided - to go with the Linux kernel's variant. So to keep it short: both approaches - are zero-copy, both have similar performance (if someone tells you something - different, he would lie due to their technical similarities) and we are using - the kernel's built-in variant to reach a broader audience. - - [1] http://lists.openwall.net/netdev/2009/10/14/37 - [2] http://www.spinics.net/lists/netfilter-devel/msg20212.html - -tcpdump - * W: http://www.tcpdump.org/ - - tcpdump is probably the oldest and most famous packet analyzer. It is based on - libpcap and in fact the MIT team that maintains tcpdump also maintains libpcap. - It has been ported to much more architectures and operating systems than - netsniff-ng. However, we don't aim to rebuild or clone tcpdump. We rather focus - on achieving a higher capturing speed by carefully tuning and optimizing our - code. That said doesn't mean that tcpdump people do not take care of it. It - just means that we don't have additional layers of abstractions for being as - portable as possible. This already gives us a smaller code footprint. Also, on - default we perform some system tuning such as remapping the NIC's IRQ affinity - that tcpdump probably would never do due to its generic nature. By generic, we - mean to serve as many different user groups as possible. We rather aim at - serving users for high-speed needs. By that, they have less manual work to do - since it's already performed in the background. Next to this, we also aim at - being a useful networking toolkit rather than only an analyzer. So many other - tools are provided such as trafgen for traffic generation. - -Wireshark/tshark - * W: http://www.wireshark.org/ - - Probably we could tell you the same as in the previous section. I guess it is - safe to say that Wireshark might have the best protocol dissector out there. - However, this is not a free lunch. You pay for it with a performance - degradation, which is quite expensive. It is also based on libpcap (we are not) - and it comes with a graphical user interface, whereas we rather aim at being - used somewhere on a server or middle-box site where you only have access to a - shell, for instance. Again, offline analysis of /large/ pcap files might even - let it hang for a long time. Here netsniff-ng has a better performance also in - capturing pcaps. Again, we furthermore aim at being a toolkit rather than only - an analyzer. - -libpcap - * W: http://www.tcpdump.org/ - - Price question: why don't you rely on libpcap? The answer is quite simple. We - started developing netsniff-ng with its zero-copy capabilities back in 2009 - when libpcap was still doing packet copies between address spaces. Since the - API to the Linux kernel was quite simple, we felt more comfortable using it - directly and bypassing this additional layer of libpcap code. Today we feel - good about this decision, because since the TX_RING functionality was added to - the Linux kernel we have a clean integration of both, RX_RING and TX_RING. - libpcap on the other hand was designed for capturing and not for transmission - of network packets. Therefore, it only uses RX_RING on systems where it's - available but no TX_RING functionality. This would have resulted in a mess in - our code. Additionally, with netsniff-ng, one is able to a more fine grained - tuning of those rings. Why didn't you wrap netsniff-ng around your own library - just like tcpdump and libpcap? Because we are ignorant. If you design a library - than you have to design it well right at the beginning. A library would be a - crappy one if it changes its API ever. Or, if it changes its API, than it has - to keep its old one for the sake of being backwards compatible. Otherwise no - trust in its user or developer base can be achieved. Further, by keeping this - long tail of deprecated functions you will become a code bloat over time. We - wanted to keep this freedom of large-scale refactoring our code and not having - to maintain a stable API to the outer world. This is the whole story behind it. - If you desperately need our internal functionality, you still can feel free to - copy our code as long as your derived code complies with the GPL version 2.0. - So no need to whine. ;-) |