RFC: Internally Generated "Records"

[Evan Huus <eapache () gmail com>]

One of the issues that's been popping up a lot recently is how to handle
"packets" that contain multiple "records". The reason both those words are
in quotes is because there's some broader context and applications:

 - Putting each application-layer PDU into its own "record" regardless of
higher-level grouping or reassembly (by e.g. TCP) would theoretically
permit filtering for packets where only (fieldA==foo && fieldB==bar) occur
together in the same "record", and not just in the same on-the-wire packet.

 - It opens up interesting opportunities for the summary list to be able
to, for example, hide everything above the application layer and only
display application-layer "records" (again, regardless of TCP-level
grouping or fragmentation).

 - It is a necessary component of dissecting record-based file formats with
the current plan of reading the entire file as a single "packet".

I've been thinking about this and trying to come up with a way to
gracefully (and backwards-compatibly) add this information to our existing
data-structures, and I'm currently thinking of just adding it as a flag to
the field_info struct (i.e. defining something like FI_STARTS_NEW_RECORD).
As far as I've been able to determine, these flag values are accessible
everywhere we need them to be (specifically: in the UI and in the
display-filter engine), and it makes creating new records
backwards-compatible and cheap (just some new macro to set the flag).

My only concern right now is how difficult it will actually be to check
this value in the display filter logic - I don't know nearly enough about
the dfvm to know if checking for fields in the same "record" is easy or not
with the info stored this way.

Thoughts? Suggestions? Better ideas?

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe