On Sun, Jun 22, 2014 at 6:43 PM, Kurt Knochner < [email protected]> wrote:
> > Zitat von Joerg Mayer <[email protected]>: > > > 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 <[email protected]> >> 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 <[email protected]> >> Archives: http://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:[email protected]?subject= >> unsubscribe >> > > > > ____________________________________________________________ > _______________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
