On Tue, Aug 27, 2013 at 5:01 PM, Joerg Mayer <[email protected]> wrote:
> On Tue, Aug 27, 2013 at 04:38:08PM -0400, Evan Huus wrote: > > We already discard a great deal of state in (single-pass) tshark that we > > keep around in Wireshark (or two-pass tshark). We do need to keep some, > > though. It's only a bug if we're keeping more than we actually need, and > > that's not determinable from the information we have here. Dario, if you > > could get us a memory profile of tshark in this situation (through > > valgrind's massif tool, for example) that would help us debug further. > > > > I dislike the idea of two-pass by default for exactly this reason: people > > expect tshark to be relatively state-less. This is already not the case, > > but it's a lot worse in two-pass mode. It might even make sense to add a > > --state-less flag to tshark that disables all options which require > state. > > I don't know how feasible that would be however. > > IIRC, two-pass allows for most/all of the reassembly/request-response > stuff, > which we want to do sometimes. Any ideas why we have to keep some > information > indefinitely? > Two-pass requires us to keep *all* the state around through the first pass so that it is available during the second pass (at which point it can be discarded). Even in single-pass mode, there is some state that we can't always immediately discard. If I see a fragment of a TCP message then it doesn't make sense to discard that until the other fragments have arrived and been reassembled. If I see a request, I probably need to keep state from that request until the response (which may never show up). We already do reassembly and a lot of other stateful work in single-pass mode. The only thing two-pass mode provides is the ability to "see the future" (for example, saying: this request has a response 5 packets later). > 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
