Hi,
>> 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
>
> If you call "finish" at the *end* of the current live capture, there won't *be* any later received packets.
>
> ("End of the current live capture" means "the entire capture is finished", not "we've finished reading the current batch of packets".)
yes, it makes sense.
The problem in this case I see with GUI. Imagine use case:
1) User starts live capture
2) User open a dialog where initiate operation which save file with
"finish" callback
3) User waits some time (e.g. till progress bar finishes) - application
will receive packets, but no "finish" callback was called
4) User closes the dialog and believes that everything is OK, but it is
not OK
It shows that application/dialog must (some of options):
a) notify user that live capture is running and operation can't be used
in point 2)
b) or notify user that live capture is running and file is not complete
in point 3/4)
c) dialog must call remove_tap_listener() before close and
remove_tap_listener() must call "finish"
Probably c) makes sense and can be implemented.
Best regards,
Jirka Novak
