Message Analyzer is different, yes. When we set out on this adventure, we weren’t trying to make a new Network Monitor 4. It’s not that you can’t get a Network Monitor type of perspective, but we are trying to expose some new ideas to make the information that is already there pop out at you while hiding some of the noise by default. Below let’s try to understand how to achieve a more familiar view.
When you go to the doctor, they tell you what’s wrong and dig into the problem from the symptoms. So for this scenario, which we are targeting in a broad sense, we focus on the idea that a network can be busy and a problem can be at any layer. But sometimes one of many, very complex systems can have an issue. So we try to bubble those up, and remove some of the lower level details by coalescing messages and combining fragments for every layer.
But this also means we simulate the complex systems. Yes, this cost a bit more on the parsing side, but given the extra insight into the system, there are advantages. Another cost is currently is order, because messages are delivered to the UI as the simulation finishes with them.
The Message Analyzer default view is different. We parse everything as much as possible, and then show you the top layer. Network Monitor, on the other hand, shows only flat messages with no reassembly, no simulation. Wireshark does a similar mixture, with some reassembly happening at the various coded and simulation as well. A difference being that Message Analyzer formalizes the definition to provide the ability in the future to create documentation, testing, and much more. But Wireshark doesn’t hide noise. For TCP reassembly, as an example, the last fragment contains the payload.
However there are cases where you want to compare to other tools to gain confidence and relate things you see. We understand that scenario and you can make some changes to help.
By coalescing, we remove the lower layers which tend to be noisier. But you can still configure Message Analyzer to give you Network Monitor like perspective, though I’ll admit it’s not perfect yet.
Call Stack – Network Monitor would show the entire network stack. Instead of intermixing it in the details, we’ve separated it into its own control. So you can easily see the entire stack regardless of your viewpoint.
Hide Operations – By default we have the ability to associate Request and Response and see the performance of the server and client. But now you can understand how two operations intermingle by hiding operations with this toggle option.
Viewpoint to “Diagnose the TCP Layer” – Now you can get rid of all reassembly above TCP using the Viewpoint Feature. Unfortunately, you can’t see the top level description like Network Monitor, but the Call Stack tells you this.
Add Time Delta column – We show TimeElapsed because it fits the theme of finding high level performance issues. But Network Monitor shows Time Delta by default. You can just add the column back using Column Chooser.
Order by Time or Message Number – This will set the order as you expect it. Message Number is what you see by default in other tools. Time order might be interesting in certain cases. However, this has some drawbacks. With large data, sorting is particularly slow. We are working on this, but for large data this might not be an option. As a work around you can find a message, using the Find tool and typing “#MessageNumber == 1234”. This will jump to the message.
Getting used to something new always has a learning curve. Our focus on simulation for diagnostic analysis, rather than just a presentation of the raw data, gives us a unique perspective to help perceive complex traffic. And we continue to work and improve scenarios across the board and to get parity with Network Monitor. But hopefully with the tips above, we can make you feel more comfortable with our new tool.
To learn more about some of the concepts described in this article, see the following topics in the Message Analyzer Operating Guide on TechNet: