[Luis EG Ontanon <luis@xxxxxxxxxxx>]

I was planning to call them "wiretap meta files" and use the .wtap extension by default. I forgot to mention that...

This is just a feature needed for the handover feature I plan to implement.

The handover between two processes requires the new process to read the packets for which there are open transactions of the prior process. The metafiles would be just the mechanism I'll use to get the new process which frames to read. How to write them is a whole different story, somewhat similar to what's done when saving related frames, that needs a lot more thinking and is not related to the many advantages of metafiles. I mentioned handovers because is what made me think of the metafile feature.

On Fri, Jul 5, 2013 at 6:30 PM, Evan Huus <eapache@xxxxxxxxx> wrote:

Two quick thoughts:
- Why the name subfiles? Index files makes more sense to me.
- It's a neat feature, but I don't see how this would solve your
problem. I'm not sure exactly what you mean by 'open transaction' in
this context though, so perhaps that would clarify.

On Fri, Jul 5, 2013 at 12:36 PM, Luis EG Ontanon <luis@xxxxxxxxxxx> wrote:
> Wiretap subfiles are to be indexes of one or more capture files (the source)
> that (as long as they correctly reference the source) transparently work as
> if they were a a single capture file with the features of the source.
>
> I think they should contain a magic number, the source filename(s),  basic
> common information from the source and a list of file_ids, framenums and
> offsets realitve to the source.
>
> They came to my mind thinking on how to make a handover between two epan
> processes so that known open transactions were not dropped when a new
> process starts, starting with a file with just the packets that contain that
> information would be the easiest way to come with it.
>
> But they can be used for tons of other things:
> - small (low disk use) saves of filter results (you just email the packet
> list back, not the file with the packets)
> - can be used as offset cache in wtap for speeding file operations
> - add your own here...
>
> I believe the implementation is a simple matter (not much more than 600
> lines of code) And I'll be starting work on it in few weeks from now unless
> someone beats me at it.
>
> Any Ideas?
>
> --
> This information is top security. When you have read it, destroy yourself.
> -- Marshall McLuhan
>

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

--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan