[Evan Huus <eapache@xxxxxxxxx>]

On Sun, Jun 22, 2014 at 6:43 PM, Kurt Knochner <ws.dev.list@xxxxxxxxxxxxxxxxxxx> wrote:

Zitat von Joerg Mayer <jmayer@xxxxxxxxx>:

What I am thinking about is something like keeping state but only for the
last 1000 (insert your favourite number here) packets and only *then* throwing it away. Or is this unrealistic?

I think that could create 'strange' side effects that are not easy to understand/troubleshoot. It could show different results if you process the same capture file, one time with 900 frames (truncated) and the other time with 1100 frames (or similar setups).

What about this: Let a disscetor decide when it's time to clear parts of its data structures. For example: The TCP dissector could drop the conversation table entry after it has seen a TCP close 'sign' (RESET, FIN, etc., or even after a defined timeout value). It would then also need a way to signal that event to upper layer (HTTP, etc.) and lower layer (IP) dissectors, so they can free their data structures as well. I'm not sure if there is an easy way to implement this in a generic way, so it will work for all dissectors (most certainly no), but maybe it's worth thinking about this a little longer to figure out if there could be a 'completely' stateless version of tshark, as this comes up quite often on ask.wireshark.org, as people want to use tshark as a long term (real time) network monitoring solution.

The problem with this approach (though it would be nicer) is that it involves mountains of work rewriting a good chunk of libwireshark and touching most if not all dissectors. If you want to do that work go ahead, but I much prefer my existing 50-line patch :)

 

Regards
Kurt

Ciao
   Jörg
--
Joerg Mayer                                           <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@wireshark.org?subject=unsubscribe