Saturday, November 01, 2008

NetMon API – Capture, Parse and and Capture File Access (with Managed P/Invoke example too)

Network Monitor - Intro to the Network Monitor API

“I’ve recently played with a new tool here at MS, which analyzes HTTP traffic and provides performance information so that you can better tune your web servers and applications. I also have seen an internal SMB expert that summarizes SMB traffic, for instance open files and connects. These types of experts provide a protocol specific view of network data that is tailored to a specific protocol. The NMAPI provides a powerful way to access our parsing and capturing engine directly. This gives you a lot of flexibility to analyze network traffic in ways you can only imagine. I want to give a quick overview of how the API works so that you can harness the power of the NMAPI.

VRTA – Visual Round Trip Analyzer

Before I dig into the API, let me show you an example of what the API can accomplish for you. It is available here:

http://www.microsoft.com/downloads/details.aspx?familyid=119F3477-DCED-41E3-A0E7-D8B5CAE893A3&displaylang=en

This tool was recently released and allows you to visualize HTTP traffic so that you can diagnose performance of your HTTP server or Browser.

VRTA

What Does the API Allow?

I like to divide the API into 3 areas, though they tend to overlap some. They are Capturing, Parsing, and Capture File access. So let me start by explaining what each can do.

Capturing: You have most of the same capabilities as you do in the UI. You can Start/Stop/Pause the capture engine on any of the network interfaces. The API lets you enumerate the available adapters and setup a unique callback for each one, if you want. Each time a frame arrives, the callback is sent the raw frame which you can then evaluate or simply save to a capture file.

Parsing: With access to the parsing engine, you can inspect any data field that is parsed. You can reassemble data on the fly to quickly parse for a few fields or enumerate through them all. You also have the same UI filtering language available to you in the API. You can define a filter as part of your frame parser and then evaluate that filter, very quickly, on each frame.

Capture File Access: The API also allows you to read and write capture files using the Netmon 2.1 file format for NM3.2.

Where is the SDK?

Almost everything is included when you install NM3.2. This includes NetMonSDK.CHM which describes each of the API and contains examples as well. The only other requirement is that you need to install the WDK. This is because we reference the NDIS headers for each adapter, which is one of the functions the API provides.

For more information on setting up your environment, see the section called Network Monitor API Overview in the CHM file. This can be accessed from the help menu in NM3.2.

Managed Code

While we haven’t created an official Managed wrapper, we have included a simple NetmonAPI.CS file which uses PInvoke to call the DLL directly. We hope to release a more proper wrapper externally at some point. Perhaps in the shorter term we can also start an open project which wraps the API.

…”

I’m such a sucker for Managed code’able API’s… ;)

I’m thinking that this could be useful to build a custom capture feature into an app to help diagnose network issues. Think about a feature where, either on demand or automagically, an application starts capturing traffic, say based on some local benchmark, to help diagnose an intermittent connectivity or performance issue. Then submits that info to a central repository for analysis… Would have to look into the deployment of it (NetMon) though.

 

Related Past Post XRef:
Network Monitor 3.2 (aka NetMon, NM3) Beta Released – Now with application network conversation tracking UI
NetMon 3.1 Released
Network Monitor 3 (aka NetMon 3, aka NM3) Re-released for Vista
NetMon 3.0 RTW

2 comments:

Jay R. Wren said...

This looks awesome, but should I install NM3.2 beta on my production laptop? It feels like it hooks itself deep enough into the OS that I should worry.

Greg said...

That's a good point. Beta can be scary especially with something like this (anything that plays with my network stack scares me a little...)

My default answer is that if you have doubts, don't do in on a Prod machine. At least do it on another machine first... And really only do if it this is going to help you solve a problem. If it's to play with, then I'd wait. If it's to solve an active problem, then it might be worth the risk...