Hi Peter,
>> 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.
Yes, you are right. I'm thinking about multiple use cases and the one
with file saving I used as easy to understand example :-)
Side note:
I briefly reviewed places where taps are used and my feeling is that
many usages do not clear memory - they don't clear structures created
during tapping. Some of them have "reset" call back, but do not call it
at the end, some of them do not handle it at all.
Therefore one of my ideas was to call "reset" callback during
remove_tap_listener(). But later I found that some code use structures
from tapping after remove_tap_listener() so it will break it.
I found that in description of tapping there is no advices/rules how to
work with memory after tapping is finished.
>> 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?
That is correct, but I have to check in every "packet" callback whether
it is right time to do so. Therefore "finish" callback looks better to me.
> 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.)
Yes, there are many approaches - I'm just thinking about options...
BTW if I will modify tapping, I must update documentation and there
should be clearly stated how "finish" call back works.
Another reason why I'm thinking about "finish" callback is voice replay
of multiple streams. My idea is to tap all streams, extract voice from
each and then "prepare" them to replay - mix it. Mix should be called in
"finish" call back - it is similar to footer for file save example.
There is same problem with live capture. Probably it is bigger problem
because play dialog stays open and with alive capture and you can't
decide to e.g. call remove_tap_listener(). In other words there is no
point where tapping code can decide that everything is finished and can
start to play.
Maybe, play dialog for live capture must say it can't play or there must
be a button "play now" which will probably remove listeners and detach
from tapping live stream.
Note: The reason why I'm thinking about mixing is that I found no
reliable way how to play synchronized multiple audio streams with Qt.
Therefore the only way I see is to mix it together to one stream and
play it then.
Best regards,
Jirka Novak
___________________________________________________________________________
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-requ...@wireshark.org?subject=unsubscribe
