Re: How code recognizes that processing of all packets with tap was finished?

[Peter Wu <peter () lekensteyn nl>]

On Fri, Jul 13, 2018 at 11:20:53AM +0200, Jirka Novak wrote:
> > On Jun 21, 2018, at 12:26 PM, Jirka Novak <j.novak () netsystem cz> wrote:
> >
> > > > > What is correct way to recognize that capture processing with tap was
> > > > > finished?
> > > >
> > > > There isn't one, unfortunately.  We'd have to change the tap mechanism to introduce a "we're done processing 
> > > > packets" callback to provide that.
>
> I'm thinking about it and I can't make clear decision about the topic,
> see below.
>
> My idea is that I will add "finish" callback. It will be called at the
> end of capture file. Probably "draw" and "finish" sequence will be called.
> Imagine that I want to write a code which will write some packets to a
> file. File has header, body and footer. Therefore I will add header at
> beginning, every "packet" callback will write data and idea is that
> "finish" callback will write the footer.
> Note: I will use no remove_tap_listener in example above.

In your earlier post, you presented freeing resources as use case, but
writing a footer is a different use case.

> What is not clear to me what should happen when live capture is running?
> I'm afraid that if I will call "finish" at the end of current live
> capture (and write footer), later received packet will be delivered to
> "packet" callback and will be written to end of file behind footer.
> On the other hand if I will not call "finish" on live capture ever (or
> only when live capture is finished), it makes no sense too - application
> will never close the file.
>
> How to handle this case?

For the freeing of resources case, how can you know for sure that a
resource is no longer used? If there is a condition for that, you could
do it from the "packet" callback as well I suppose?

For the footer scenario, if you write it too early, the file can no
longer be extended. You can only reliably complete it when the user
stops the packet capture. Potentially you could check for the elapsed
time between the last relevant packet and the current packet time from
the "packet" callback and decide on writing a footer. Or rely on the
"draw" callback to process a snapshot (and calculate times from there).
(An additional "finish" callback would still be necessary in case the
"draw" callback decides to delay writing the footer.)
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe