Wireshark mailing list archives
Re: How code recognizes that processing of all packets with tap was finished?
From: Peter Wu <peter () lekensteyn nl>
Date: Fri, 13 Jul 2018 11:37:38 +0200
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
Current thread:
- Re: How code recognizes that processing of all packets with tap was finished? Jirka Novak (Jul 13)
- Re: How code recognizes that processing of all packets with tap was finished? Guy Harris (Jul 13)
- Re: How code recognizes that processing of all packets with tap was finished? Jirka Novak (Jul 13)
- Re: How code recognizes that processing of all packets with tap was finished? Guy Harris (Jul 13)
- Re: How code recognizes that processing of all packets with tap was finished? Jirka Novak (Jul 13)
- Re: How code recognizes that processing of all packets with tap was finished? Jirka Novak (Jul 13)
- Re: How code recognizes that processing of all packets with tap was finished? Guy Harris (Jul 13)
- Re: How code recognizes that processing of all packets with tap was finished? Peter Wu (Jul 13)
- Re: How code recognizes that processing of all packets with tap was finished? Jirka Novak (Jul 13)
- Re: How code recognizes that processing of all packets with tap was finished? Guy Harris (Jul 20)