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?
