Re: Wiretap subfiles

[Luis EG Ontanon <luis () ontanon org>]

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 () gmail com> 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 () ontanon org> 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 () 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
> ___________________________________________________________________________
> 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



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

___________________________________________________________________________
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