The Processing Sequence

We outline the major processing sequence the protocol analyzer uses to process data. An appreciation of these steps is vital to understanding certain aspects of protocol decoding.

The Processing Sequence image illustrates this sequence.

At the top, captured data is fed through a Frame Recognizer if required. Once that is done we can view the capture as a sequence of frames awaiting decoding. The rest of the diagram traces the processing of a single frame.

The first step in processing a frame is to feed it through the Frame Transformer to prepare it for decoding, if such is required.

The second step, which like the first is optional, is to pass the frame to a Preprocessor Method. We have not mentioned these before because preprocessors are seldom used.

Preprocessors can do two things. They can set up inter-frame data and initialize fields.

The next step is to run the decoder and display the results in the protocol analyzer Frame Display window.

After decoding, a Postprocessor method may be run. Like preprocessors, post processors are rarely used. One example is provided by the decoder for Van Jacobson compressed headers (VJC.DEC) which uses a postprocessor to store inter-frame data.

The next step in the flow may involve the invocation of one or more methods that help set things up for working with the next protocol layer. Specifically they may determine what protocol is used, where the layer starts and how long it is. When the next protocol can vary (i.e. when it is not fixed in the stack definition that the user has specified) then a NextProtocol Method must be provided. This dynamically figures out what protocol comes at the next layer. If the next protocol is fixed in the stack definition then any NextProtocol Method specified in the decoder is ignored. By default, the next layer is assumed to start immediately after the current one and either extend to the end of the frame or define its own length. If there is padding or a gap before the next layer then a NextProtocolOffset Method must be supplied; its job is to determine how many bits must be skipped. Finally, when the next layer does not extend to the end of the data, a NextProtocolSize Method is required to calculate the length of the next layer. Note that if a NextProtocolOffset or a NextProtocolSize method is defined then it is always invoked even if the NextProtocol Method is not.

The next step is the optional processing of the frame by another Frame Transformer method. It rarely happens that frame modification is needed at this stage but it can be appropriate if the current decoder needs to make any adjustments before the next decoder gets hold of it. You can see examples in the decoders for Van Jacobson headers (VJC.DEC and VJU.DEC). VJU replaces the byte that specifies that the frame should be saved for VJC with a value indicating that the next protocol is TCP. This allows the VJU frame to look just like an IP frame so the standard IP decoder can be invoked. VJC takes the saved IP header from the VJU frame decoded earlier, modifies it, and then creates an entirely new frame with that and the rest of the payload from the current frame, and passes that back as the new frame to use.

The final job is to check if the end of the frame has been reached. If it has then the decoding of the frame is complete. Otherwise we loop back and start processing the next layer.